Python后端部署排障06：curl 没报错，为什么业务请求还是失败了
网络层已经连通，curl 也输出了一段 JSON，于是你在群里说“恢复了”。几分钟后用户仍无法确认报价：原来 JSON 是一个版本冲突错误，HTTP 状态为 409，curl 却默认以零退出。这个小坑揭示了本课的核心：命令执行成功、HTTP 收到响应、业务操作成功，是三件需要分别验证的事。
我们从可观察的 HTTP 请求开始，不急着安装代理和证书。先在本机回环地址运行本专题自带的 QuoteOps，用 curl 检查方法、请求头、body、响应头和状态，再完成一次创建、读取、确认、旧版本拒绝的业务闭环。下一课把同一服务装进镜像，业务合同不会因为换了运行方式就改变。
E05 完整答案：TCP 成功还不是 HTTP 成功
执行python3 lessons/06/answer_previous.py。输出包含系统解析的地址、数字主机模式对非数字名字的拒绝、未监听端口的拒绝，以及开始监听后的连接成功。接收端确实读到了ok，但它没有解析 HTTP 方法，也没有返回状态行，因此不能用它证明 HTTP 服务已经就绪。
lessons/06/answer_previous.py
"""不依赖公网DNS；只占用一个OS自动分配的回环TCP端口。"""importjsonimportsocketdefmain():addresses=socket.getaddrinfo("localhost",80,type=socket.SOCK_STREAM)resolved=sorted({item[4][0]foriteminaddresses})assertresolvedtry:socket.getaddrinfo("quoteops.invalid",80,flags=socket.AI_NUMERICHOST)exceptsocket.gaierror:numeric_lookup="rejected"else:raiseAssertionError("AI_NUMERICHOST must reject a nonnumeric host")# 持有bind保证端口不会被别的进程抢走，但尚未listen。withsocket.socket(socket.AF_INET,socket.SOCK_STREAM)aslistener:listener.bind(("127.0.0.1",0))address=listener.getsockname()try:withsocket.create_connection(address,timeout=5):passexceptConnectionRefusedError:refused="refused"else:raiseAssertionError("A bound but unlistened TCP socket must refuse")listener.listen(1)listener.settimeout(2)withsocket.create_connection(address,timeout=2)asclient:peer,_=listener.accept()withpeer:client.sendall(b"ok")assertpeer.recv(2)==b"ok"result={"resolved":resolved,"numeric_lookup":numeric_lookup,"address":list(address),"unlistened_tcp":refused,"listening_tcp":"connected"}print(json.dumps(result,ensure_ascii=False,indent=2))if__name__=="__main__":main()这个答案把所有 socket 放在上下文管理器中，结束即关闭，也没有为了复现失败修改本机 DNS 配置。受控实验的目的就是用少量变量看清机制。真实故障可能跨越很多层，但训练时不必一口气引入互联网、公司代理和负载均衡，否则每次失败都难以知道自己到底验证了什么。
先运行自带项目，数据库迁移要显式执行
本专题project/包含报价服务全部源码，以下命令不引用前两课题的目录。建议 Linux Python 3.11，从课程根目录执行。虚拟环境只负责隔离 Python 包，不会隔离内核、端口或文件权限；SQLite 数据目录也仍受当前 UID 控制。环境变量为应用指定同一数据库绝对路径，迁移命令必须对准它。
python3.11-mvenv .venv .venv/bin/python-mpipinstall-e./projectmkdir-p.lab/localexportQUOTEL_DATABASE="$PWD/.lab/local/quotes.db".venv/bin/python-mquoteledger.migrations--database"$QUOTEL_DATABASE".venv/bin/python-muvicorn quoteops.api:create_app--factory--host127.0.0.1--port18080--no-access-log最后一条在前台运行。另开一个已进入课程根目录的终端发送请求；结束用 Ctrl-C，让应用走停止流程。若端口占用，应查清原进程或选择另一空闲端口，后面的 URL 同步调整。不要为了抢一个端口结束不属于自己的程序。远程实验通过 SSH 隧道访问时，也要区分本地隧道端口和远端实际监听端口。
应用工厂不会自动替你迁移数据库，这是刻意的边界。启动日志出现不等于 schema 已经准备好；/health回答进程能否处理一个简单请求，/ready检查存储是否可提供服务。如果漏做迁移导致 ready 返回 503，应先核对配置和库路径，再补正确的部署步骤，而不是无限重启应用。
curl 的每个参数都在选择一个观察角度
curl-sS--connect-timeout2--max-time5-ihttp://127.0.0.1:18080/readycurl-sS--max-time5-D.lab/local/response.headers-o.lab/local/response.json-w'%{http_code}\n'http://127.0.0.1:18080/health-sS隐藏进度条但保留错误，-i把响应头和 body 一起输出，适合人工观察。自动处理时用-D保存头、-o保存 body，-w输出状态码，可以避免 JSON 与状态行混在一起。--connect-timeout限制连接相关阶段，--max-time给整个操作总期限；总期限不是数据库事务的取消保证，客户端超时后服务端可能仍在执行。
默认 curl 收到 404、409、503 等有效 HTTP 响应，通常仍以零退出。使用支持该选项的 curl 版本时，--fail-with-body会对四百以上状态给非零退出码，同时保留 body；但本课故意测试 409 时不能把它当成意外崩溃。判断应把预期状态写清楚，不能简单规定“所有非二百都是网络失败”。
-I发送 HEAD，请求语义与 GET 不同，某些路由不支持它会返回 405；这不能证明 GET 不可用。-X POST选择方法，-H添加头，--data-binary发送指定数据。JSON body 不会因为看起来像 JSON 就自动获得正确 Content-Type，所以应明确声明application/json。教程示例使用 Bash 引号规则，PowerShell 用户不要假定复制所有单引号细节就完全相同。
一次创建请求，至少检查四个地方
curl-sS--max-time5-i-XPOST http://127.0.0.1:18080/quotes-H'Content-Type: application/json'-H'X-Request-ID: ops-create-01'--data-binary'{"sku":"OPS-E06","supplier":"lab","quantity":3,"unit_cents":1299,"shipping_cents":500}'成功创建应为 201，响应Location指向/quotes/<id>，X-Request-ID回显本次合法请求标识，body 中total_cents为四千三百九十七。计算是三乘一千二百九十九，再加五百，金额单位全部是分。不能只看到一个 id 就认为创建合同完整，也不能把 JSON 中的小数金额拿去与整数分随意混算。
本服务接受由字母、数字、下划线和连字符组成的有限长度 request_id；不合格的值会由服务端重新生成。每次请求使用新的标识，才能把一次客户端观察与一次服务日志关联起来。request_id 不是鉴权凭据，不需要把用户 token 或报价内容塞进去。后面的日志课会验证代理和应用如何传递同一个标识，以及哪些数据不能进入日志。
读取刚创建的路径应该返回同一报价、草稿状态和版本一。确认时发送{"expected_version":1}，成功后状态为 confirmed、版本二。再发送同样的旧版本一，必须得到 409 和version_conflict。这不是服务不稳定，而是服务正确拒绝了基于旧快照的写入。最后再读取一次，证明失败请求没有改变已确认报价和金额。
状态码是定位线索，不能替代业务含义
| 状态 | 在本课程中的解释与下一步 |
|---|---|
| 400 | 常见于请求格式或协议层拒绝，先确认响应来自哪个组件；本服务的模型校验通常用 422 |
| 404 | 路由不存在或报价不存在，结合 body 的错误代码区分 |
| 409 | 版本冲突或状态规则冲突，读取最新状态再决定用户意图，不能自动覆盖 |
| 422 | 请求结构或字段约束不符，例如 quantity 为字符串，先修调用方输入 |
| 500 | 应用未处理异常，保留 request_id，对应查应用错误日志 |
| 502 | 代理无法得到合适上游响应，检查上游地址、监听与连接情况 |
| 503 | 当前不可提供服务，本项目常见于存储未准备好或不可用 |
| 504 | 代理等待上游超过期限，检查耗时阶段与各层预算 |
这张表不是说“任何 503 都由 SQLite 引起”，不同组件可以生成相同状态。要结合响应头、错误结构、日志和访问路径定位产生响应的一层。后面 Nginx 课会真实制造 502 与 504，本课不靠随便返回一个数字来伪装已经复现代理故障。
还有一种危险情形：客户端收到超时，没有拿到 HTTP 状态。你不知道写操作是否已经提交，立刻重发可能创建两张报价。当前创建接口没有宣称提供幂等键合同，所以课程不会给所有 POST 自动加重试。读取操作、状态变更和创建操作需要分别分析；版本号能拦住陈旧状态转换，却不能自动给独立的两次创建去重。
从“有响应”走到可重复验收
手动 curl 适合观察，但完整回归要自动检查状态、头和 body。下一课的标准库答案把 HTTPError 当成仍有响应内容的对象读取，因为 409 是本题需要检查的结果；连接失败和超时则继续报错。它还会禁用继承的 HTTP 代理配置，确保本地或 SSH 隧道实验按声明路径直连。这是测试环境选择，不代表生产系统永远不需要代理。
每次练习会创建一张新的报价留在本次实验库中，这是有意的业务证据，而不是临时文件泄漏。课程部署清理时会处理自己的实验卷；若你在共享业务系统操作，应该先选择专用测试环境，不能为了“清理干净”去删除不属于自己的记录。把可写范围提前定义清楚，后面的发布与回滚验收才可重复。
收到错误以后，先决定谁拥有修复动作
如果请求字段类型不对，调用方应修正输入；如果报价版本已经变化，用户或上层流程需要重新读取并决定操作意图；如果应用内部抛出异常，运维需要用请求标识找到对应记录。把所有错误统一弹出“请重试”，会把这些不同责任混在一起，也可能把一次正确的并发保护变成不断重复的冲突。
确认接口的旧版本失败尤其适合训练这种判断。第一次确认已经改变了服务端事实，第二次请求仍宣称自己看到版本一，服务器没有义务替它猜测“也许用户只是没看到成功提示”。它返回冲突，让调用方明确读取最新状态。这种行为保护了业务规则，验收时应把它当成成功防护的一部分。
记录响应时同样要有边界。排查只需要方法、路由、状态、耗时和请求标识时，就不要顺手保存所有请求体、查询参数和凭据。手动使用详细输出选项可能显示认证头，分享终端记录之前需要确认内容。我们用非敏感的固定练习数据，是为了让学习过程尽量容易复查，同时为后面的日志白名单建立直觉。
E06：用一张报价检验整个 HTTP 合同
E06：针对运行中且 ready 的 QuoteOps，完成五次请求。创建数量三、单价一千二百九十九分、运费五百分的报价，要求 201、正确 Location、合法且一致的 X-Request-ID、金额四千三百九十七分；读取要求草稿和版本一；携带当前版本确认，要求确认状态和版本二；用旧版本一再次确认，要求 409 与version_conflict；最后读取，要求与确认后的快照完全相同。
程序接受--base-url，默认http://127.0.0.1:18080，每次请求有五秒超时和独立 request_id；不得自动重试 POST，不得忽略失败断言。第七课会给出lessons/07/answer_previous.py全文并实际用于容器服务验收。到那时，镜像构建成功只是起点，这份业务合同才会告诉我们：运行方式改变后，服务行为是否仍然正确。
课程目录：《Linux、网络与后端部署排障：从“接口能跑”走到“服务能维护”》 · 上一篇：第05篇 · 下一篇：第07篇
