独立修改一个业务需求

先定义什么才算改完

在工程副本中完成本章，保留原始版便于对照。新规则只改变数量上限，不改变输入输出结构：

• 数量 1 和 5 可以创建；0 和 6 不可以。
• HTTP 提交 6 返回 422，而不是 201 或数据库导致的 500。
• 内存与新建 SQLite 数据库都遵守该规则。
• 原来的查询、取消、TCP 查询仍正常，响应字段不改变。

先确认前面临时破坏规则的练习已经恢复，再运行基线测试。若这里失败，先修复基线，否则无法判断后面失败是不是由新需求引起。

go test ./... -count=1

数量   旧规则   新规则
0      拒绝     拒绝
1      接受     接受
5      接受     接受
6      接受     拒绝
20     接受     拒绝

其中 6 是最有用的反例：它在旧系统合法，在新系统非法。只测试 0 和 100，即使什么都不改，也可能全部通过。

先判断修改会经过哪些文件

先自己找一遍，再展开对照。问题不是“哪里出现了数字 20”，而是“哪里定义或验证了数量规则”。不要全局替换：并发测试也有 20，它代表 goroutine 数量，不是购买上限。

先改测试，让旧实现明确失败

先只修改三个测试文件，暂时不改业务和 SQL。测试也属于需求的一部分，不是实现改完以后再随手把断言改绿。

例如业务接受边界原本是下面这段，只改变列表里的上边界即可：

func TestQuantityBoundary(t *testing.T) {
	service := order.New(memory.New())
	for _, qty := range []int{1, 20} {
		if _, err := service.Create(context.Background(), order.CreateInput{SKU: "coffee", Quantity: qty}); err != nil {
			t.Errorf("quantity %d should be accepted: %v", qty, err)
		}
	}
}

go test ./internal/order ./internal/httpapi ./internal/sqlite -count=1

TestRejectInvalidOrder：quantity=6 被接受，预期 ErrInvalid
TestHTTPFailures/large_quantity：得到 201，预期 422
TestQuantityConstraint：quantity=6 落库成功，预期拒绝
FAIL

1 和 5 的成功测试此时仍通过，这是正常的。失败必须指向“6 被错误接受”，而不是编译错误、端口占用或文件路径错误。如果全部 PASS，检查是不是只改了合法边界，却没有加入 6 这个反例。

先改业务，再收紧新数据库的约束

现在修改 internal/order/service.go：校验条件中的 input.Quantity > 20 改为 input.Quantity > 5，ErrInvalid 说明中的 quantity must be 1..20 改为 quantity must be 1..5。不要改变 ID 生成、时间或保存顺序。

go test ./internal/order ./internal/httpapi -count=1

现在这两个包应通过；但 SQLite 约束测试仍会失败，因为它刻意绕过 Service，表还允许 6。修改 internal/sqlite/schema.sql 的 quantity BETWEEN 1 AND 20 为 quantity BETWEEN 1 AND 5，再运行：

go test ./internal/sqlite -count=1
go test ./... -count=1

order、httpapi、sqlite：数量边界测试 PASS
memory / sqlite：共享存储契约 PASS
app：HTTP 创建、TCP 查询、取消后再查询、停止与启动失败检查 PASS

测试每次用临时目录创建新数据库，因此会使用修改后的内嵌 schema。至此实现与测试一致，但还要用运行中的程序验证一次，防止只改了副本却启动了旧目录。

用真实请求验收，不靠测试结果猜测

先停止旧服务。在修改后的工程根目录，使用一个未使用过的练习文件名；若 quantity-five.db 已存在，请另取新名。不要删除或覆盖 lesson.db。

go run ./cmd/orders -db quantity-five.db -tcp 127.0.0.1:8088

在编辑器里把 requests/create.json 的 quantity 临时改成 5，保留 sku 为 coffee。保存后发请求，Windows 使用 curl.exe：

curl -i -X POST http://127.0.0.1:8080/orders -H "Content-Type: application/json" --data-binary "@requests/create.json"

应返回 201、quantity 为 5。记下这笔订单 ID，然后把文件中的 quantity 改为 6，再执行同一条请求命令，应返回 422 与 invalid_order。这个 422 应来自 Service 校验，而不是把 SQLite 的 CHECK 错误当作业务提示。

curl -i http://127.0.0.1:8080/orders/ORDER_ID
go run ./cmd/ordercli -id ORDER_ID
curl -i -X POST http://127.0.0.1:8080/orders/ORDER_ID/cancel
go run ./cmd/ordercli -id ORDER_ID

创建 5 → 201；创建 6 → 422
HTTP 和 TCP 查询 → 同一 ID，quantity 都为 5
取消后再用 TCP 查询 → 同一 ID，status 为 cancelled
重启同一数据库后查询 → 仍为同一笔订单

停止服务，重启同一数据库验证最后一项。再停止并改用 -memory 启动，把请求文件中的 quantity 依次设为 5、6，重复两次创建，证明规则不依赖 SQLite。全部验证后，把 requests/create.json 恢复为 quantity 2，避免通用示例请求一直处于拒绝状态；业务上限保留为 5。

为什么这还不是一次旧库迁移

本次实验使用新数据库。如果把程序指向原 lesson.db，CREATE TABLE IF NOT EXISTS 不会把旧表的 CHECK 从 20 改为 5；正常 Service 新建仍会拒绝 6，但数据库本身仍是旧约束。两件事必须分开验证。

真实旧库可能已经有数量 6–20 的历史订单。产品需要先回答：新上限是否只管新订单？历史订单是否仍应可查询和取消？若需要保留它们，简单给全表加上限 5 可能与历史数据冲突。这里不能通过删库“解决”，需要带版本、可验证、可回退的迁移方案。

换成自己的需求，从一个可验收操作开始

假设你的项目是房间服务，第一项需求不是“搭一套分层架构”，而是“输入房间名和容量，创建房间并能查回；空名字、容量越界时拒绝”。先写这些输入与结果，再把它们放到已经认识的位置：

接着先完成一条从创建到查询的完整路径，再增加加入、离开等变化。不要先复制所有文件夹；当一个职责确实出现时，再找到它的位置。鉴权、支付、库存等未实现能力仍需应用或网关另外设计。

需要脚手架和契约生成时，可继续看 同版本的 Golden Path。你现在应该能判断：生成工具替代的是哪些重复的组装或协议代码，哪些业务决策必须自己写。本例没有宣称已经接入 OpenAPI 生成。

用一条链检查是否真正理解整个项目

合上教程，从 POST /orders 开始，自己画到 Service.Create、Store.Create，再画回 201；在旁边补上“main 选 Store，app 创建并传递对象”。然后回答下面三问，并去源码确认：

1. 数据库写失败时，哪个函数最先知道？谁决定 HTTP 500，谁记录内部详情？
2. 新增一种协议时，哪些业务测试应一行不改？怎样证明它访问了同一份数据？
3. 把数量上限改成另一个值时，能否自己补一个先失败、后通过的边界测试？

能运行、追踪、修改并验证这一条链，你就不只是在认识函数用法，而是在用这些组件完成一个项目。