导语：待办应用是 CRUD 练习。这一篇开第二个真实案例：在线图片工具站（图片压缩 + 加水印）——有文件上传、有后台处理、无账号体系，是个人开发者最容易上线赚钱的形态。
23-27 篇你做了待办应用，学会了完整的 Web 全流程。现在换一个完全不同形态的项目：在线图片工具站——用户上传一张图，选择"压缩"或"加水印"，下载处理后的图。
为什么选它：无账号体系、有文件上传、有后台处理任务——这是个人开发者最容易做出来、最容易上线、最容易被人用起来的形态（每个人都需要压缩图片）。
一、五块知识总表
| # | 知识 | AI 做什么 | 你做什么 | 前置知识 |
|---|---|---|---|---|
| ① 选型 | FastAPI + 原生前端 | 搭骨架 | 看懂结构 | 05（Python 框架） |
| ② 图片处理库 | Pillow | 写处理代码 | 看懂调用 | 23（实操） |
| ③ 文件上传 + OSS | 上传逻辑 | 写接口 | 配密钥 | 21（对象存储） |
| ④ AI 生成代码 | 需求模板 | 写全部代码 | 提需求+验收 | 22（工作流） |
| ⑤ 本地跑通 | 跑起来 | 改报错 | 验证功能 | 23（实操） |
经验：每一块都是你学过的知识换个用法——没有新语言、没有新框架，全是旧知识的新组合。
二、逐块拆解
① 选型：FastAPI + 原生前端
为什么是 FastAPI（05 篇）：轻量、自动出接口文档、适合工具型后端。前端用最简单的原生 HTML/JS（06 篇）——工具站不需要框架。
你做的：看懂"后端接口 + 前端页面"的结构（23 篇的路由-数据库对照表同款思路）。
② 图片处理库：Pillow
图片压缩、加水印的核心库。你不需要会图像算法——让 AI 用 Pillow 写，你要看懂两件事：
- 压缩：
img.save(..., quality=80)降低质量 = 文件变小； - 水印：
img.paste(logo, position)把 Logo 贴到图上。
经验：图片库选对了，整个项目难度降一半——选型（Pillow）比实现重要。
③ 文件上传 + 对象存储（衔接 21 篇）
用户上传的图怎么存？分两档，别一上来就全套 OSS：
新手起步档（先用这个）：原图存服务器临时目录，处理完立刻删；只有结果图传对象存储 OSS，给用户下载链接。
- 流程：上传 → 服务器临时目录 → 处理 → 结果传 OSS → 返回下载 URL → 删临时原图。
量大了再升级：原图也直接传 OSS（21 篇的完整方案）——但新手阶段，临时文件短期放服务器目录是合理的。
和 21 篇的关系要分清：21 篇"别存服务器本地"说的是长期存用户文件（头像、相册、内容素材）；工具站的临时处理文件用完即删，短期放本地没毛病——别把两件事混成"一个字都不能存"。
你做的：创建子账号 AccessKey（别用主账号，21 篇红线），把密钥放进环境变量。
④ 让 AI 生成代码（22 篇工作流）
需求模板（接着 23 篇的对话风格）：
"帮我做一个图片工具站：用户上传图片，选'压缩'或'加水印'。后端用 FastAPI，图片处理用 Pillow，处理完的图传到阿里云 OSS 并返回下载链接。上传大小限制 10MB。先讲思路再写代码，前端用最简单的原生 HTML 页面。"
你要做的：①拆任务（一次一个功能：先上传→再压缩→再水印）②验收（22 篇：跑起来验证）。
⑤ 本地跑通
在本地把项目跑起来（23 篇的经验）：
uvicorn main:app --reload # 启动后端（FastAPI 的启动命令）
浏览器打开页面上传一张图 → 压缩 → 下载 → 功能通。
经验：本地跑通 = 项目完成 70%——剩下 30% 是部署（39 篇），而部署你 25-27 篇已经会了。
三、和待办应用（CRUD）的差异
| 维度 | 待办应用（23-27 篇） | 图片工具站（本篇） |
|---|---|---|
| 核心操作 | 增删改查文本 | 上传/处理/下载文件 |
| 数据 | 存数据库 | 文件存 OSS + 少量记录 |
| 账号 | 无（也可以无） | 无账号体系（更简单） |
| 后台任务 | 无 | 同步处理（上传→处理→下载，一趟完成，不是异步队列） |
| 用户场景 | 自己用 | 给别人用（工具站） |
经验："无账号 + 文件处理"是个人工具站的标配——比带账号的项目少一半工作量（登录注册、权限、找回密码全是坑）。
四、避坑清单
- 别存服务器本地：说的是长期存用户文件才存 OSS（21 篇）；工具站临时原图用完即删、结果图进 OSS。
- 上传大小限制：不限制会被传爆（10MB 上限起步），后端要校验（15 篇：接口参数别裸奔）。
- 别只限文件大小，还要限图片尺寸：一张 1MB 的高压缩 JPEG 解压后可能几千万像素，Pillow 直接吃光内存（甚至触发 DecompressionBomb 保护）——让 AI 在代码里限制图片像素上限（如长边不超过 8000px），超大图直接拒绝。
- 处理大图会超时：处理大图耗时，接口会超时——限尺寸 + 限大小双管齐下（新手够用，流量大了再上异步队列）。
- 别一上来加账号体系：工具站先无账号跑通，有用户了再加（33 篇：验证优先）。
- 密钥进环境变量：OSS 的 AccessKey 绝不写进代码（21/32 篇双红线）。
- 先本地跑通再部署：别急着上服务器——本地都跑不通，部署只会更乱（25 篇经验）。
总结
- 新案例：图片工具站（压缩+水印）——无账号、有上传、有后台处理，个人最容易上线的形态。
- 五块知识全是旧知识新组合：选型（05）→ Pillow 图片库 → 上传/OSS（21，新手先临时目录+结果图进 OSS）→ AI 生成（22）→ 本地跑通（23）。
- 和待办应用差异：文件替代文本、结果图进 OSS、同步处理（不是异步队列）、无账号更简单。
- 经验心法：选型比实现重要（Pillow 选对难度减半）；本地跑通 = 完成 70%。
- 避坑四条：临时文件用完即删、限上传大小、还要限图片像素（防内存炸弹）、别急着加账号、密钥进环境变量。
10 分钟小任务：想一个你自己的"图片工具"点子（压缩/加水印/去背景/改尺寸都行），写三行需求：用户上传什么 → 工具做什么 → 用户拿到什么。下一篇，把这个项目从"能跑"变成"上线"——服务器、Docker、Nginx、SSL 全走一遍。
下一篇：案例（中）：从能跑到上线——服务器、Docker、Nginx、SSL 全走一遍。