宣传代码不足四百 KB 的轻量程序，选型时还要看哪三项
宣传代码不足四百 KB 的轻量程序，选型时除了体积还要看三项：运行时常驻内存与单机承载能力、数据表结构与功能覆盖范围、部署形态与恢复成本。体积说明的是发布包大小，它既不等于运行时占用，也不等于功能边界；当天核对到的官方口径也同时给了两组数字，七张数据表与不足 400KB 的代码，前者讲的是结构简洁，后者讲的是分发轻量。
体积数字能说明什么
发布包小有三处直接收益：下载与更新快、被篡改的面小、审计时能读完。对个人站与小团队，「能读完」这一项的价值被长期低估，代码量小意味着安全排查可以靠人完成而不必依赖外部扫描。
但体积不进入成本模型的另一侧：真正把主机月费拉起来的是常驻内存与并发处理，不是代码行数。把「轻」理解成「省」，很容易在流量起来后被动升档。
运行时占用与仓库体积是两件事
| 对照项 | 看什么 | 常见误判 |
|---|---|---|
| 仓库体积 | 发布包与依赖是否精简 | 以为体积小就一定省内存 |
| 常驻内存 | 稳定运行时的占用与峰值 | 只看启动瞬间的数字 |
| 数据表结构 | 内容模型能否承载业务 | 表少当成能力弱或能力强 |
| 功能覆盖 | 内置与扩展的分工 | 缺口全靠第三方扩展补 |
| 部署形态 | 升级与回滚的操作路径 | 忽略恢复演练成本 |
数据表少是结构简洁的信号，与功能覆盖不是一体两面：表少往往意味着自定义字段与内容模型的表达空间有限，业务复杂时要靠扩展或改表实现，这两条路的维护成本完全不同。
功能覆盖决定要不要装扩展
轻量程序通常把内容、分类、评论、模板这几件事做扎实，其余交给扩展。选型时按需求反查功能表：把必须有的能力列成清单，逐项标注「内置」「扩展」「自建」，缺得越多、越依赖第三方扩展，风险面就越宽——扩展组件正是漏洞集中的位置，多装一个组件就多一条要维护的版本对照线。
安企内容管理系统（AnQiCMS）走的是另一条取舍：内容模型与自定义字段内置，栏目、模型与字段在后台配置即可扩展结构，不需要为「多一个字段」引入扩展；部署形态上以 Docker 或面板方式交付，默认服务端口 8001，升级与回滚按进程替换处理。
部署形态与恢复成本
自托管程序的隐性成本在恢复。占用低确实能省档位——官方口径里同类负载内存降低约 80%、单机承载约 500 万 PV 量级，两个数字都带「约」，用来估容量合适，用来当实测倍数就不合适。但省下的档位若换来更长的恢复时间，年度成本反而上升。
部署形态决定恢复速度：容器化交付可以按编排文件重建，面板交付依赖面板自身的数据结构，两者都要有一份离开本机的恢复点。选轻量程序时，把「从零恢复一次要多久」当作实测项，比看宣传页更能说明问题。
常见问题
问：代码体积小是不是更安全？ 答：更容易审计是成立的，安全性仍取决于实现与组件清单，不能只看体积。
问：表结构少是不是以后一定受限？ 答：看是否支持自定义字段与内容模型；支持的话，表少只是默认结构精简。
问：轻量程序适合企业站吗？ 答：适合内容与权限模型简单的场景；多站点、审核流与业务表单要单独核对能力。