小不等于未完成。它意味着每个组件职责清晰、依赖经过斟酌，并且从请求到结果之间始终可见。
可见性是一种特性
当运维人员能说出每个边界时，他们也能指出缺少哪份证据。日志变得更有用，告警更具体，例行维护风险更低。
对静态网站而言，重要的边界通常很容易列出：
- DNS 把主机名指向预期的边缘。
- TLS 在预期的代理处终结。
- 代理只服务一个已知的输出目录。
- 输出只包含站点需要的文件。
- 404 响应由站点本身处理，而不是意外的上游。
把这些写下来，比加上一块回答不了任何上述问题的仪表盘更有价值。
复杂性要用实力取得位置
当新的一层消除的不确定性多于它引入的，它才值得。缓存重要时，给资源加指纹的构建步骤会有用；内容需要事务时，数据库才有用。但对一个小而多为静态的站点，这两者都不必然是改进。
对客户端 JavaScript 也适用同一规则。如果页面确实需要客户端脚本，应选择满足需求的最小实现，并有意识地审查内容安全策略。对本站而言，这首先需要重新评估已接受的零脚本架构及其验证契约，并不是当前策略的例外。如果页面是一份文档，纯 HTML 往往更容易检视、更有韧性。
让所有权明确
每个文件都应有存在的理由与明确的更新方式。vendored 主题应记录其上游版本与许可。生成目录应标记为生成物。资源下载应说明它包含什么、何时更新、校验和如何产生。
这些简短声明能防止未来的运维者把偶然产生的制品当作受支持的接口。
为下一次变更留出空间
最好的小系统不是行数最少的那个，而是下一次变更看得见去处的那一个。笔记站可以从 Markdown、静态生成器与一个 Web 服务器起步；如果以后需要搜索或评论，可以独立评估这个新需求，而不是一开始就假设它存在。
规模小并不自动带来容错。一个边缘、磁盘或运维者仍可能成为单点故障。明确可接受的恢复时间与数据损失，保留独立备份并演练恢复。组件更少的好处是需要理解的故障路径更少，而不是不会停机。
来源
- Hugo directory structure，内容与资源的目录约定，已核验 2026-07-27。
- Caddy
file_server指令，设计中引用的静态文件服务默认值，已核验 2026-07-27。
