1在dede网站后台改文章删除图片或者用Dw修改文章和替换图片之后

很多站长在维护dede网站时，习惯直接在后台编辑器里把文章中的图片删掉，或者用Dreamweaver打开模板文件去修改代码、替换图片。操作完了，页面确实变了，但服务器里留下的烂摊子，往往要过很久才暴露出来。这篇文章就把这些问题摊开讲清楚。

后台编辑器里删除一张图片，实际上只是把文章内容里的``标签移除。dede系统的附件管理记录并不会随之删除，uploads目录里的原始图片文件也原封不动地躺在那里。也就是说，你看到的是删除了，但服务器上那块硬盘空间照样被占着。一个普通企业站，图片平均大小在150K到300K之间，如果每周更新十篇文章，每篇去掉两张旧图，一个月就积攒近80张废图，一年下来接近1000张，白白浪费掉200多兆空间。这还只是中小企业站的规模，换成资讯类门户，几年不清理，几个GB的垃圾文件都算正常。

更隐蔽的问题出在数据库里。dede的文章正文存在`dede_addonarticle`表的`body`字段中，附件信息则记录在`dede_uploads`表。当你在后台删掉图片，`body`字段里没了引用，但`dede_uploads`表里依然保留着文件路径、上传时间、大小等记录。这些无效记录会让后台附件列表越来越长，检索速度下降。尤其当你用“已使用”和“未使用”筛选附件时，那些删掉图片相关的记录会归类为“未使用”，数量多了以后，每次打开附件管理页面都要加载很久。

再说用Dreamweaver修改文章。不少人为了快速调整版面，直接用Dw连接数据库或者修改模板，然后上传替换图片。这种方式最危险的是编码问题。dede的数据库默认使用utf8或gbk，而Dw有时会默认改成别的编码，一旦保存时没注意，整个页面的中文就变成乱码。即便编码没出问题，Dw强大的“智能修复”功能也常自作主张改动代码结构，比如给``标签加上`style`属性，或者把单引号改成双引号。这些看似无关紧要的变化，轻则让图片显示尺寸异常，重则直接破坏dede自带的响应式布局判断。

替换图片同样有讲究。如果你只是用FTP把uploads下的某张图片覆盖成新内容，文件名不变，那么页面显示没问题，但dede生成的缩略图不会自动更新。举个例子，文章列表页调用的是`图片名_lit.jpg`这类缩略图，而内容页调用原图。当FTP覆盖了原图之后，访问内容页能看到新图，可列表页依旧显示旧的缩略图。这是因为缩略图的生成依靠后台函数触发，绕过后台直接覆盖文件，dede根本不知道图片变了。很多站长遇到列表页图片不换新，还以为是缓存问题，清了半天缓存，结果根源在这里。

还有一类情况容易被忽略。删除或替换图片后，搜索引擎的图片索引还会保留旧的URL。如果原来的图片已经被收录，那么一旦物理文件被真正删除，或者新图片换成了不同文件名，页面返回404。站点的图片搜索流量会逐渐流失，同时404错误也会让搜索引擎对整站的可信度打分下降。根据一个长期跟踪的案例，某资讯站因为清理了三千张未用图片，同时修正了所有引用链接，三个月后图片搜索流量下降了约17%，整个自然搜索流量也出现了轻微波动，可见图片处理对SEO不是小事。

比较稳妥的做法是，在后台删图时，不要只在编辑器里移除，而是去后台的“附件管理”找到对应文件，执行真实删除，这样数据库记录和物理文件能同时清掉。如果需要用Dw修改文章代码，建议先备份数据库和原始文件，修改完成后用dede自带的前台生成重新生成页面，确认无误再覆盖，并且注意在Dw中将文档编码设置为与dede站点一致。替换图片时，如果要保持文件名一致，最好同步去后台重新上传一次图片，让dede重新生成所有尺寸的副本；如果必须直接用FTP覆盖，就得手动清理浏览器端和服务器端的缓存，同时检查列表页和首页调用的缩略图文件是否也被覆盖。

说到底，dede的后台逻辑并不复杂，但它有自己的规则。跳过这些规则的操作，短期内看不出问题，长期积累下去，空间占用、数据库膨胀、SEO下降都会找上门。每次修改完文章，花两分钟去附件管理里确认一下图片状态，比事后花半天清理垃圾要省心得多。