设计原则总结
从一张 8.7MB 的图片说起
六个月前，“光影”上线第一天，一张 8.7MB 的 RAW 照片拖垮了整台服务器。那是我第一次意识到——图片系统不是”存个文件”那么简单。
六个月后的今天，“光影”支撑着 12000 个摄影师、85000 张图片、日均 15 万次页面浏览。我坐在电脑前，回顾这个从 0 到 1 的过程，把踩过的坑、想明白的道理，提炼成了 8 条设计原则。
这些原则不是从教科书里抄的。每一条背后，都是凌晨三点的告警短信。
原则 1：原图不可丢
用户上传的原图是唯一的数据源，缩略图可以重新生成，原图丢了就真的丢了。
实践：原图保护机制
原则 2：渐进增强
永远有兜底方案。用户应该先看到内容，再看到更好的内容。
实践：前端渐进加载
原则 3：成本意识
从第一天就关心成本。不是省钱，是确保项目可持续。
实践：成本仪表盘
原则 4：缓存为王
如果一个问题可以通过缓存解决，那就用缓存解决。
实践：多级缓存配置
原则 5：异步优先
能异步的就不要同步，用户等得起的结果，不要让他等着。
原则 6：安全纵深
安全不是一道墙，是一层又一层的防护。
原则 7：可观测先行
如果你看不见，你就管不了。
实践：核心监控面板
原则 8：简单至上
不要为了技术而技术。最简单的方案往往是最好的方案。
“光影”从 0 到 1 的数据回顾
六个月的完整数据：
最后的话
写到这里，“光影”的图片系统设计课程就结束了。
回头看，这不是一个关于”最优架构”的故事。这是一个关于问题驱动迭代的故事——从一张 8.7MB 的图片拖垮服务器，到支撑 12000 用户的生产级系统。
每一个技术决策都是在具体问题下做出的，而不是凭空设计的：
图片太大？→ 压缩 + 格式转换
用户等太久？→ CDN 加速
审核不过关？→ 多层审核机制
成本太高？→ 冷热分离 + 生命周期管理
看不到问题？→ 监控告警系统如果你正在构建自己的图片系统，我希望这 8 条原则能帮到你：
1. 原图不可丢 → 数据是一切的根基
2. 渐进增强 → 永远有兜底
3. 成本意识 → 确保可持续
4. 缓存为王 → 最简单的性能方案
5. 异步优先 → 不让用户等不需要等的东西
6. 安全纵深 → 多层防护
7. 可观测先行 → 看不见就管不了
8. 简单至上 → 复杂度是未来的问题没有过度设计，只有问题驱动的迭代。
这就是我从”光影”学到的最重要的事。
我的思考
思考 1
如果这 8 条原则只能保留 3 条，你会保留哪 3 条？为什么？
我会保留这 3 条：
1. 原图不可丢（原则 1）
- 没有数据，一切都是空谈
- 图片系统的核心价值就是用户的图片
- 其他所有问题都可以修复，唯独数据丢失不可逆
- 这也是为什么我把软删除、版本控制、分目录存储放在最前面
2. 缓存为王（原则 4）
- CDN 缓存解决了 80% 的性能问题
- 浏览器缓存解决了重复访问的延迟
- Redis 缓存解决了数据库压力
- 缓存是投入产出比最高的优化手段
3. 可观测先行（原则 7）
- 你无法优化你无法测量的东西
- 冷热分离的前提是知道哪些是冷数据
- 成本优化的前提是知道钱花在哪里
- 缓存优化的前提是知道命中率是多少
- 监控是一切优化的起点
为什么不是”渐进增强”或”简单至上”？
- 渐进增强很重要，但它更像一种实现策略，而非设计哲学
- 简单至上也很重要，但在特定场景下，复杂度是必要的（如消息队列）
- 而这 3 条是所有决策的基石：保护数据、用缓存加速、靠数据驱动
思考 2
“光影”的架构如果要支撑 10 万用户，哪些原则需要调整？
10 万用户（约 8 倍增长）下，部分原则需要升级：
需要调整的原则：
原则 4（缓存为王）→ 需要更精细的缓存策略
当前：CDN 缓存 + Redis 缓存
10 万用户后：
- CDN 多 Region 部署
- 引入本地缓存（进程内 LRU Cache）
- 缓存预热策略更激进（热门图片提前推送到边缘）
- 缓存一致性更复杂（多 Region 同步）原则 8（简单至上）→ 部分组件需要自建
当前：全托管（OSS + CDN + 云审核）
10 万用户后：
- 可能需要自建图片处理服务（云 API 费用太高）
- 可能需要自建 CDN 源站（节省回源流量费）
- 但核心思路不变：自建是为了省成本，不是为了炫技不需要调整的原则：
原则 1（原图不可丢）：100 用户还是 100 万用户，原图都不能丢。 原则 2（渐进增强）：无论规模多大，兜底方案永远需要。 原则 3（成本意识）：规模越大，成本意识越重要。 原则 6（安全纵深）：用户越多，攻击面越大，安全越重要。
核心洞察：前 4 条原则（数据、渐进、成本、缓存）是规模无关的——它们在任何规模下都适用。后 4 条原则（异步、安全、可观测、简单）在规模增长时需要调整具体方案，但原则本身不变。
思考 3
回顾”光影”的 6 个月，如果让你重来一次，你会怎么安排开发优先级？
如果重来，我会按这个顺序开发：
第 1 周（生存线）：
✅ OSS 存储 + 客户端直传 + 文件大小限制
✅ 基础缩略图生成（WebP + JPEG）
✅ 监控系统（第一天就上 Prometheus）
→ 目标：能用，能监控
第 2 周（体验线）：
✅ CDN 加速
✅ <picture> 渐进增强
✅ 懒加载 + 骨架屏
→ 目标：快
第 3~4 周（安全线）：
✅ 内容审核（鉴黄 + OCR）
✅ Referer 白名单 + STS 凭证
✅ 频率限制
→ 目标：安全
第 2~3 月（成本线）：
✅ AVIF 格式支持
✅ 存储分层（冷热分离）
✅ 生命周期管理
✅ 成本监控仪表盘
→ 目标：可持续
第 4~6 月（规模线）：
✅ 弹性伸缩
✅ CDN 边缘裁剪
✅ 完善监控告警
→ 目标：抗增长与实际的区别：
- 监控从第 5 个月提前到第 1 周
- CDN 从第 2 个月提前到第 2 周
- 审核 from 第 2 个月提前到第 3 周
- 缩略图从一开始就生成多格式（WebP + JPEG），不走过场
核心改变：先让系统可观测、可用，再迭代功能。不是先堆功能再补监控。