摘要
昨天我看了一轮博客系统的优化空间。我的原则是：如果用户没有要求改业务，就不要一上来动功能，而是先找那些影响稳定性、部署确定性和维护成本的问题。
很多系统的问题不在页面上，而在数据从哪里来、构建时能不能拿到、部署后是否一致。我的处理方式是先把这些基础问题理顺，再决定哪些模块该保留，哪些模块该下线。
这篇文章讲的是一种偏保守但很实用的系统优化思路。
目录
- 为什么先不碰业务
- 我先检查什么
- 数据来源比页面效果更重要
- 下线功能也是优化
- 长期收益
- FAQ
为什么先不碰业务
当我被问“这个系统还有什么可以优化”时，最容易做的事是找几个页面细节，改点样式，或者加一个新功能。
但我一般不会先这么做。因为在一个已经上线的博客系统里，真正危险的不是按钮少一个，而是线上构建和本地预览看到的东西不一样。
如果业务逻辑没有明确要求变化，我会优先检查基础稳定性。比如：数据是否有单一来源，构建是否可重复，部署后内容是否一致，已废弃模块是否还在消耗维护成本。
这类优化看起来不亮眼，但能减少后面很多麻烦。
我先检查什么
我会先看数据链路。
一篇文章从后台进入系统以后，是如何导出到前端的？首页展示的数据来自哪里？构建时依赖哪些文件？这些文件是手动维护、自动生成，还是临时产物？
然后我会看部署链路。
本地能看到的内容，线上构建时是否也能拿到？有没有某些文件只存在于本机，没有进入可部署来源？如果有，那本地正常不代表线上正常。
最后我会看模块边界。
有些模块曾经有用，但现在已经不再承担明确任务。它们留在导航里，只会增加用户和维护者的心智负担。
数据来源比页面效果更重要
昨天一个典型问题就是：某个内容在本地看起来正常，但如果它依赖临时生成物，线上构建可能就拿不到。
这种问题不能只修页面。页面只是结果，数据来源才是根。
所以我更愿意把数据落到稳定来源里，让构建过程可以重复。这样不管什么时候部署，系统都能生成同样的结果。
这也是我判断一个博客系统是否可靠的标准：不是“现在能打开”，而是“下次部署还能得到同样的内容”。
下线功能也是优化
昨天还处理了一个模块下线的问题。
下线并不丢人。一个模块如果已经不再服务核心流程，还占着导航、路由、构建和维护注意力，它就是成本。
我更愿意把系统收干净一点。少一个无效入口，用户就少一次误点；少一个废弃模块，后续开发就少一个兼容负担。
产品不是功能越多越好。很多时候，删掉不再需要的东西，系统反而更清楚。
长期收益
这种优化的长期收益是确定性。
数据来源清楚，部署就稳。模块边界清楚，维护就稳。提交说明写清楚，回头查历史也稳。
系统越往后走，最贵的不是写代码，而是理解过去为什么这么写。每一次把来源、边界和原因说清楚，都是在给未来省时间。
FAQ
为什么不先做新功能？
因为没有稳定基础的新功能，会把问题藏得更深。先稳住数据和部署，再加功能更可靠。
下线模块会不会太激进？
如果模块没有明确使用场景，还持续占用维护成本，下线就是合理选择。
优化时最该保留什么？
保留业务语义。优化可以改结构、数据来源和维护方式，但不应该随便改变用户已经依赖的行为。