CMS的附件机制通常是上传即入库。在编辑器里插入一张图，文件写进上传目录，同时在数据库的附件表里留一条记录，记录带文章ID。删除文章时，正文记录被删掉，附件表的关联字段被清空，磁盘上的文件却留了下来。文件按年月分目录存放，同一篇文章的图片和不同文章的图片混在同一批目录里，时间一长，目录里的文件数远多于在用图片数，靠人工比对几乎无法判断哪些还在被引用。上传目录与程序以同一身份运行，脚本误删与正常删除在日志里看不出区别。
被忽略的另一半占用
上传原图之后，主题或插件会按不同尺寸生成多个副本，副本文件名带尺寸后缀，不在附件表里单独记录；原图删掉之后，副本仍留在目录中，且不会被任何后台列表显示出来。一台跑了三年的站点，缩略图的数量通常是原图数量的三到五倍，尺寸多的主题会生成五到六个副本，每个都单独占空间。
多数备份方案按整站打包，附件目录一并进入压缩包。孤立文件越多，每个备份包越大，备份耗时与存储占用同步上升，恢复到新服务器时会把多余体积一并带过去，原本几分钟的恢复被拖成几十分钟。
把上传目录的文件清单与附件表、正文中引用的文件名做交叉比对，得到目录里有、库里没有的集合，这个集合才是候选。直接按修改时间删除，会把草稿和待发布文章里的图片一并清掉，而这类文件在后台列表里同样看不到。这一步可以用脚本完成，也可以在后台导出附件列表之后用表格比对。
顺序反了会清掉草稿图
有些主题在模板里用固定路径引用图片，这类文件不出现在正文中，也不在附件表里，按常规比对会被判为孤立。清理工具如果只查数据库，需要先把模板目录排除在外，否则首页与列表页的配图会在清理后集体失效。
还有一类孤立文件来自重复上传。同一张图在不同文章里各传一次，磁盘上留下多份副本，文件名带随机后缀，附件表里各占一条记录，正文只引用其中一份。按引用比对能把这批筛出来，但内容相同，删除时须保留最早的那一份，否则正文会跟着失效。这类文件体积不小，累积几百个之后，占比不比缩略图低。
删除之后要观察什么
删除之前导出候选文件的路径与体积，保存成文本。清理之后观察一到两周，重点看三处：文章页的图片是否完整、列表页的缩略图是否显示、搜索结果里的配图是否还在。磁盘空间的回收是即时的，缺图往往要等到读者反馈才被发现，观察期的意义就在这里。确认无误之后，再从历史备份中清除这批文件，否则下一次恢复会把它们原样带回来。观察期不宜太短，索引与缓存更新本身也需要时间。
申请创业报道，分享创业好点子。点击此处，共同探讨创业新机遇！
