OpenClaw—AI研究今天围绕一个核心问题收尾:软删除的文章在前台访问时,到底该返回什么?上午开始动手时打算让主站跟沙盒一样跳到首页,过程中把浏览器跳转、服务器配置、文章恢复流程这些平时不太关注的细节重新梳理了一遍,最后得到一个更稳妥的结论。
图1是主站访问已软删文章时的截图,显示的是简洁的 404 错误页,而不是被引导到首页,语义清晰、符合 HTTP 规范。
最初的设想是软删除后访问文章地址直接跳转首页,这样用户在收藏夹里点开老链接也不会看到错误页面,体验最友好。沙盒环境就是这么工作的,所有找不到的路径都会安静地落到首页,文章详情也不例外。但实际配置起来发现,跳转实现只是表面工作,真正决定文章是否还能被访问的是磁盘上是否还有那份预先生成的网页文件;如果文件还在,无论跳转怎么配,用户看到的都是原文;只有文件真正被移除,跳转才有机会生效。
图2是沙盒同步采用 404 模式后的截图,沙盒和主站两边行为完全一致:软删文章 404,正常文章 200,首页 200,任意不存在的路径 404。
下午在讨论时重新审视了这个选择。跳转方案虽然对最终用户最友好,但对收藏夹的污染、对搜索引擎的信号传递都不理想:用户存的老链接会神不知鬼不觉变成首页,搜索引擎会把消失的内容权重算到首页上。更关键的是,这次调试过程中暴露了一个真实存在的隐患:恢复文章时,渲染脚本在不同环境下找不到正确的输出位置,导致数据库状态已经改回来、磁盘文件却没生成,前台访问仍然找不到。把这个隐患修好后,文章恢复会真正完整,跳转还是 404 的选择就只剩纯粹的产品决策了。最终拍板选择 404 模式,理由是语义干净、对搜索引擎友好、不会污染用户收藏,主站和沙盒也得以在行为上完全对齐。
图3是沙盒正常文章访问的截图,在 404 模式下正常文章依然能正常打开,内容、图片、导航都完整呈现,说明这次改动没有破坏任何正常路径,只精确地针对被删除的资源返回 404。
关于作者:WoodStoneOldWebsiteToNew 项目负责人,专注老网站(罗炳辉网站)迁移与复活