从第零章开始，
学会为一个小项目做设计。

本轮提供学习页

同一个网址，为什么两个人的学习进度不同？

先修：会使用浏览器；不要求编程或安装工具。

1. 分清输入、处理、状态和输出；代码下载的位置与运行的位置。
2. 把观察、候选解释、实现证据分开：刷新仍保留、另一浏览器看不到，只是现象。
3. 结合存储记录与已核对代码判断当前实现；保留尚未观察或核实的边界。

核心练习：在固定 HTTPS 课件页记录“输入—刷新—换浏览器”的结果；阅读给出的存储／实现证据卡，再修改最初画的图。使用临时测试文字，不清空自己的正常学习进度。

错例诊断：“刷新还在，所以一定只存本地；另一浏览器没有，所以绝对没有后端。”请给出一个也能产生类似现象的候选解释。

参考判断／自评要点：服务器按会话隔离数据也可能得到类似现象。判断当前课件用本地存储，需引用存储项及对应代码；有限的一段网络记录不能证明世界上不存在任何后端。图上分别标出观察、核实事实与未知。

带走的成果：一张带证据等级的系统图与一份“已知／未知”记录。

小迁移：改成一个天气网页：同一网页文件、城市选择和天气数据是否一定在同一处保存？至少写出一个仍需核实的问题。

依据与选读：MDN · How the web works · MDN · Client-server overview · C4 model · System context diagram

本轮提供学习页

看到新内容，是否意味着向服务器保存了数据？

先修：第 0 章；阅读 JSON 的就地补课卡。

1. URL、DNS、HTTPS 与 HTTP 按职责解释；示意过程和直接观察分开标注。
2. 读取地址、方法、状态、请求体、响应体；知道一次请求记录能证明和不能证明什么。
3. 对比静态文件 GET、业务数据 GET／POST，以及浏览器内部的界面变化。

核心练习：浏览器主线阅读本轮附带的后端实测请求记录，并可在 Network 面板观察本课 HTML 的 GET。逐项标注请求、响应和写后再读的证据；绘制读取与创建流程。手动运行 Python 标准库＋SQLite 演示后端为选做，不作为进入下一章的条件。

错例诊断：“页面多了一条笔记，就证明服务端数据库已经写入。”请指出缺少哪两类证据。

参考判断／自评要点：界面变化只说明页面状态改变；需查看写请求与响应，再结合后续读取及已知后端实现说明持久化。时序图不能把未直接观察的数据库步骤画成 Network 面板的实测事实。

带走的成果：一份请求证据记录，以及读、写各一张时序图。

小迁移：为“查询快递”和“修改收货地址”各画一条请求路径，标出只有后者需要改变的业务状态。

依据与选读：MDN · How the web works · MDN · Client-server overview · Helsinki Full Stack Open · Fundamentals of Web apps · Harvard CS50 Web · Lecture 3: Django

目录计划；正文与证据包待制作

一个个人笔记工具，第一版到底需要哪些东西？

先修：第 0–1 章；不要求了解云产品目录。

1. 先拆清跨设备：手动导出／导入、联网自动同步、两个设备并发编辑是不同要求。
2. 固定第一版：个人使用、两台设备先后联网使用，打开或刷新时取得已提交的新内容；支持基本增删改查、拒绝未授权读取、低维护投入。离线同步和实时协作暂不做。
3. 按责任划分比较“自己写业务 API＋数据库”和“浏览器调用托管数据服务＋服务端访问规则”；二者都可能托管，不能把“单后端”和“托管”当互斥类别。

核心练习：先判断纯本地＋手动导入能否满足所写需求，再在两种真正满足自动同步要求的方案间作选择。用下方同一张决策表逐项对照，不从产品名称倒推需求。数据规模、预算和开发时间先写假设，再标验证办法。

错例诊断：“只要跨设备，纯本地就永远不合格；托管方案一定比单个后端省钱。”请分别补足“跨设备”的定义和成本证据。

参考判断／自评要点：若只要求手动迁移，本地方案可以成立；只有硬性要求自动同步时，纯本地才单独不够。两候选必须满足相同需求，再比较开发、运维、迁移与规则约束。可接受不同选择，但须写清代价和改选条件。

带走的成果：一页需求与约束、两张可行候选图、一份统一决策表。

小迁移：把笔记工具换成离线旅行清单：哪些要求变化会让本地优先成为更合适的选择？更新决策表而非只换图标。

同约束下的两候选与统一决策表

以下是教学假设，不是产品报价：个人低频使用、两设备先后联网访问、刷新取得最新已提交内容、仅本人可读写，不要求离线协作。先核实两方案均能满足这些要求，再比较责任和维护代价。

两种选择都可成立。最终选择须引用自己的约束和核查证据；“托管”不等于不需设计权限，“自写 API”也不等于必须自己买服务器。后续每章都更新同样的“需求—方案—代价—选择—改选条件”五栏。

依据与选读：C4 model · System context diagram · C4 model · Container diagram · MIT 6.033 · Syllabus & Design Project（2018）

目录计划；正文与证据包待制作

关页、重启、写到一半失败，以及两次不同编辑，会发生什么？

先修：第 2 章；SQL 语法按任务提供，不要求先学完整数据库课程。

1. 3A · 存储：比较浏览器存储、进程内存、文件和数据库；用关页／重启后的已给结果判断持久化边界。
2. 3B · 关系：用户、笔记和标签；稳定 ID、所有权、必填和唯一约束。只学读懂当前模型所需的 SQL。
3. 3C · 事务与冲突：哪些多步写入必须整体成功；A、B 从同一旧版本各自编辑时，B 的保存可能覆盖 A。先写“不静默丢失已确认编辑”的业务要求，再比较拒绝旧版本、人工合并或明确允许最后写入覆盖。

核心练习：每小课只交一张表：存储与故障表、模型与约束表、正常／回滚／旧版本编辑结果表。读双窗口记录：A、B 都读到 v1，A 写 v2，B 仍基于 v1 保存。区分两个独立编辑与同一个创建请求的重试。

错例诊断：“已经用了事务或幂等键，因此两个窗口的编辑都不会丢。”找出它遗漏的冲突条件。

参考判断／自评要点：事务的整体成功与去重同一操作，都不自动决定不同编辑的冲突策略。必须点名业务不变量、旧版本如何识别及冲突如何反馈；不能把所有拒绝都叫重试。详细隔离级别、锁与 SQL 实现列为深化选读。

带走的成果：存储选择、数据关系图、三条不变量、一个事务边界与一个冲突判断。

小迁移：改成读书清单：新增一本书、修改短评、扣减最后一个预约名额，哪类操作需要更强的并发规则？预约只作加难情境。

依据与选读：Harvard CS50 SQL · Lecture 2: Designing · PostgreSQL Tutorial · Transactions

目录计划；正文与证据包待制作

前端说“保存”，后端究竟承诺做什么？

先修：第 1、3 章；核心路线用请求记录，不依赖 Web 框架安装。

1. 创建、读取、修改的输入输出与错误含义；客户端反馈和服务端验证分工。
2. 服务端对直接请求仍须验证；前端输入框限制不构成服务端验证证据。
3. 用请求编号串联日志与响应；列表分页仅解释输入、返回与上限。

核心练习：比较两份记录：表单在发请求前拦住空文本；受控演示中绕过表单直接发送非法输入。对后者同时核对请求体、错误响应、写前和写后数据（内容与条数）。在本人运行的演示环境可选手动复现，不向不明第三方服务试探。

错例诊断：“我点保存看到了红色提示，所以数据库肯定没收到坏数据。”请指出该观察还没有检查哪个边界。

参考判断／自评要点：指出表单可能根本没发请求；服务端证据需包含到达它的非法请求、约定响应和数据未被错误改变的前后对照。用 400 或 422 等约定均可，关键是契约一致且不能只有页面提示。

带走的成果：API 契约、输入边界和可核实的正常／错误案例。

小迁移：为照片说明接口增加长度上限：分别写出浏览器的帮助性提示和服务端必须执行的规则。

依据与选读：MDN · Client-server overview · Helsinki Full Stack Open · Fundamentals of Web apps · Harvard CS50 Web · Lecture 3: Django

目录计划；正文与证据包待制作

登录了，为什么也不能读取别人的笔记？

先修：第 3–4 章；身份系统采用成熟组件，密码学不作为前置。

1. 认证回答“是谁”，授权回答“对这个对象能做什么”。
2. 所有者、分享者和游客的最小权限；从服务端验证的身份判断，而不相信请求自报的 owner。
3. 每个对象请求都检查权限；失败响应不能泄露不该读取的内容。

核心练习：阅读课程提供的两个测试账号请求记录，比较本人 ID、他人 ID 和未登录访问；说明列表与单条接口各自应怎样限制。自行复现只用课程隔离环境；本轮演示不等于已实现生产认证。

错例诊断：“隐藏别人的笔记按钮，再把编号改得很长，就不需要服务端权限检查。”指出直接请求仍然存在的路径。

参考判断／自评要点：用户能构造请求。矩阵须覆盖读／改／删和对象所有者；至少列出未登录、读取他人、修改他人三类拒绝。拒绝后既不泄露正文也不改变数据。

带走的成果：权限矩阵、校验位置，以及至少三条拒绝访问案例。

小迁移：将私人笔记改为“只读分享链接”，写出谁能读取、谁能修改、撤销后如何拒绝的一页契约。

依据与选读：OWASP · Authorization Cheat Sheet · Harvard CS50 Web · Lecture 3: Django

旧样板素材；完整新章待重写

第一次已经写入，又点一次会怎样？

先修：第 1、3–5 章；先分清同一操作重试与不同编辑的冲突。

1. 核心判断：超时可能发生在写前或写后；不能把没收到成功等同于没保存。
2. 核心判断：同一次创建重试需保留操作身份；不同内容、不同操作和不同编辑冲突应分别处理。
3. 核心判断：哪些错误可重试、次数／总时长上限、何时提示用户结果仍未知。深化实现：去重记录与写入的原子性、并发唯一约束、有效期和保留策略、退避抖动。

核心练习：阅读并使用旧样板的故障模拟，把结论回填第 4 章接口。必做只要求正确判定与有边界的协议；模拟不是网络或数据库并发实测。深化选做才编写并发去重和事务测试。

错例诊断：“超时就换一个新操作编号无限重试；最终成功一次就说明只写入一次。”指出两种可能重复和一个资源边界。

参考判断／自评要点：同一业务意图重发保留身份；新意图使用新身份。说明写前失败和写后丢响应都成立，列出重复、冲突、过期及永久错误路径，并限制请求总量。去重机制不能顺便解决两个独立编辑互相覆盖。

带走的成果：可靠保存协议，包含结果未知、操作身份、有限重试与验收案例。

小迁移：把新增笔记换成发送邮件：重试产生的副作用有什么不同？哪些承诺需要新的证据，不能照搬模拟结论？

依据与选读：PostgreSQL Tutorial · Transactions · AWS Builders’ Library · Timeouts, retries, and backoff with jitter

目录计划；正文与证据包待制作

“我这里能用”之后，怎样知道别人也能正常使用？

先修：第 4–6 章；核心路线阅读三个小型证据包，不要求注册云账号或搭监控平台。

1. 7A · 发布：核对网址、版本、配置和一条正常读写路径。部署版本与业务数据分别记录。
2. 7B · 观察：用一条失败请求及少量延迟、成功率和日志找下一步；区分网址／配置错误与业务逻辑错误。
3. 7C · 恢复：分别阅读代码回滚记录与数据库在新副本恢复记录，检查恢复后的版本、条数、内容与业务操作。

核心练习：完成三个短任务，每次只回答“看到什么、支持什么、下一步查什么”。提供逐项参考判断与错例，先在证据上判断。真实部署、监控服务接入和备份恢复操作属于选做深化，不把搭平台变成通过本章的条件。

错例诊断：“上线返回 200 就证明用户保存正常；我有备份文件，按回滚按钮就能把误删数据找回。”将两处跳步分别改成可核验步骤。

参考判断／自评要点：发布要验版本和关键业务路径；日志需关联同一请求，不仅看一个 200。回滚代码不自动恢复数据；备份必须通过恢复后检查才证明可用。先在隔离副本验证，记录恢复范围和可能丢失的时间窗口。

带走的成果：发布核对表、一次定位记录、一份代码回滚与数据恢复的核验表。

小迁移：换成家庭菜谱站：页面发布错了与菜谱记录误删各选哪条恢复路径？为每条写一个成功证据。

依据与选读：Google SRE Workbook · Monitoring · PostgreSQL · SQL Dump / Restore · Cloudflare Pages · Rollbacks

目录计划；正文与证据包待制作

列表加载慢，应该换服务器、改查询，还是加缓存？

先修：第 3、4、7 章；判断原则简读，性能实现实验按需要选做。

1. 区分延迟、吞吐和并发；将一次请求分成可观察的阶段。
2. 在相同数据与访问条件下比较查询和索引，记录读收益、写代价和空间代价。
3. 先定义可接受陈旧时间和隐私边界，再决定是否缓存及如何验证或失效。

核心练习：从给定的分段耗时和查询记录定位瓶颈，比较一次只改一个因素的结果；选择“改查询／加索引／暂不缓存”并填写决策表。自行造数据和压测属于深化。

错例诊断：“页面慢，先加缓存；任何人的列表都用同一个缓存键。”指出一条缺失的测量和一条隐私风险。

参考判断／自评要点：结论要指向观测到的耗时段；前后对比须保持数据与请求条件可比。缓存决定需包含用户隔离、允许陈旧多久、失效办法和不缓存的可行方案。一次小样本变快不能证明所有负载都改善。

带走的成果：瓶颈证据、可比较的改动前后记录和缓存采用条件。

小迁移：收藏夹的新条目要求立刻可见，而书评统计允许晚几分钟。哪部分更适合缓存，为什么？

依据与选读：Harvard CS50 SQL · Lecture 5: Optimizing · MDN · HTTP caching · Google SRE Workbook · Monitoring

目录计划；正文与证据包待制作

导出大量笔记时，用户必须一直等着请求吗？

先修：第 3、4、6–7 章；判断原则简读，中间件实现选做。

1. 同步完成与返回任务 ID 的区别；接受请求不等于任务已经完成。
2. 按需求比较直接执行、数据库任务表与队列；后台执行程序负责什么。
3. 处理确认前后崩溃、重复执行、失败重试和积压；对用户展示可解释的状态。

核心练习：在已给时序记录中标出待执行、运行、成功、失败；判断处理程序在副作用前后崩溃时会怎样。保留最简单可行方案，不要求安装 RabbitMQ。

错例诊断：“进入队列就是成功；消息确认之后，任何业务动作都不会重复。”指出任务状态和业务副作用各缺什么证据。

参考判断／自评要点：成功须以最终产物和相应记录为依据；重复投递与业务去重分开设计。说明重试上限、失败可见性以及队列增长时的降载或等待反馈。按需求采用任务表也可以通过。

带走的成果：任务状态图、重复处理规则与积压时的反馈策略。

小迁移：比较生成文件和发送通知：哪种重复处理易于重建，哪种会直接打扰用户？更新重复规则。

依据与选读：RabbitMQ · Work Queues · AWS Builders’ Library · Timeouts, retries, and backoff with jitter

目录计划；正文与证据包待制作

换一个项目，你能重新做决定，而不是复制笔记应用吗？

先修：第 0–7 章；第 8–9 章按项目需要补入。

1. 常规项目选收藏夹或习惯记录；预约工具是加难选项，须补名额不超卖等并发不变量与争抢验收。
2. 贯穿需求、责任与状态、业务不变量、正常／失败路径、方案代价、证据和修订触发条件。
3. 明确预算与能力假设、已知限制和后续验证；设计稿不冒充已实现系统。

核心练习：独立完成初稿，然后使用课程提供的反例卡自查并修订；不依赖助教或自动评分。反例至少覆盖断网、重试、越权、旧版本编辑、恢复；可选请同伴按同一表反馈。至少保留两种满足相同要求的候选方案。

错例诊断：“我把笔记改名为预约，再加数据库和队列，所以它就是正确设计。”找出会导致两个用户同时拿到最后名额的遗漏。

参考判断／自评要点：按七项自评：需求可验、责任明确、状态可定位、不变量清楚、失败路径完整、候选可比、改选条件有证据。任一项只列产品名或空泛承诺就回到对应章节；多种方案可合格，前提是与约束一致。

带走的成果：有可行备选、有验收证据计划、有改选条件的小项目设计说明。

小迁移：最终换一个新约束（离线使用／多人分享／访问增长），只修改受影响的决定，并解释为何其他部分仍可保留。

依据与选读：C4 model · System context diagram · C4 model · Container diagram · MIT 6.033 · Design Project