话说回来，折腾这“空间关闭”的事儿，是去年的事了。当时手里有个老项目，好久没动了，服务器，数据库，还有些乱七八糟的服务，一直开着，每个月都在那里扣钱。虽说钱不多，但看着心里就不爽，想着赶紧把这些玩意儿都给彻底关了。
第一次申请，碰壁！
我当时就觉得，这不就是动动手指头的事儿嘛上去那个管理后台，找到了“服务管理”的选项，然后点进去找到那个项目对应的“空间”，毫不犹豫地就点了个“关闭申请”。提交上去，心里还想着这下省心了。结果？没两天，邮件就来了，说我这申请“不予通过”。当时我肺都快气炸了，这什么鬼？关个东西还这么费劲？
邮件里就甩了一句：“您的空间仍有未结清的资源或存在活动中的服务，请检查并解决后再试。”就这么简单一句话，再没了。我当时就蒙了，什么叫“未结清的资源”？什么叫“活动中的服务”？我明明把能停的都停了！
抽丝剥茧，寻找原因
没办法，这钱还在扣着，我不能就这么算了。我开始一点点地排查。我先是登录了那个云服务的控制台，把所有跟这个项目沾边的服务都点开看了一遍。我以前干事儿，就喜欢一股脑地上，想着反正测试阶段，资源多配点儿没关系，结果这时候就麻烦了。
- 查日志，找线索：我先把所有相关的服务日志翻了个遍。果不其然，发现有个后台脚本，我以为早就停了，结果它还在悄悄地跑！虽然没啥大的操作，但它时不时地会去访问一下数据库，留下一条条小记录。这不就是那个“活动中的服务”嘛怪不得关不掉。
- 翻配置，理清单：我又把这个空间绑定的各种配置项都捋了一遍。发现有个远程存储桶，当时为了方便，直接给这个空间开了读写权限，结果里头还放着几张图片，虽然不大，但它就是个“未结清的资源”！还有，我当时测试的时候，随手创建了一个测试账户，结果忘了删除，那个账户一直挂在那里，也算是个隐患。
- 琢磨依赖，断链子：最坑爹的是，我后来才发现，我当初为了图省事，把这个项目的数据库，跟另一个小项目共用了！虽然那个小项目已经不怎么用了，但它的几个定时任务，偶尔还是会去这个数据库里捞点儿数据。这就是个隐形的依赖，我没发现它，人家系统却一眼就看出来了。真是牵一发而动全身！
就这么一点点地扒拉，才把这些藏着掖着的问题都给揪出来了。那时候我才明白，这系统不是我用眼睛看就能知道它在干啥的，它有它自己的逻辑判断。不把我这边的所有小尾巴都处理干净，人家是不会让我顺利关掉的。
对症下药，逐一解决
知道了问题在哪儿，那就好办了。我当时就给自己列了个清单：
- 立即停止并删除活动脚本：赶紧登录服务器，把那个还在运行的后台脚本彻底给停了，然后把相关的定时任务也全删干净。
- 清理存储桶并解绑：把存储桶里的那几张图片全删了，然后把这个存储桶跟我的项目解绑。
- 删除测试账户：把那个只剩个壳子的测试账户也给删了。
- 剥离数据库：这个最麻烦，我联系了那个小项目的负责人，跟他说明情况，最终协调下来，把数据库里的数据给导出来，然后彻底把两个项目给分开了，确保这个项目自己的数据库再没有任何外部依赖。
前前后后折腾了好几天，我真的是把这个“空间”里的每一个角落都翻了一遍，确保所有的服务都停了，所有的资源都清理了，所有的依赖也都断了。心里反复确认了几遍，觉得这回应该万无一失了。
再次申请，大功告成
一切都处理妥当之后，我战战兢兢地又去管理后台，再次提交了“关闭申请”。这回我心里没底，但想着反正能做的我都做了。又过了两天，邮件又来了。这回邮件内容不一样了，标题是“您的空间关闭申请已通过”！我当时看着这几个字，长长地松了口气，心里一块大石头总算落了地。
这事儿给我最大的教训就是：别看是关个东西，没你想的那么简单。尤其是你用了人家的平台，很多时候人家系统看得比你仔细。平时做事儿，养成好习惯，用完的资源及时清理，不必要的依赖早点儿断掉，不然到头来，一个小小的关闭操作，也能把你折腾得够呛。
