“上传图片经常失败”还不是可复现问题。需要让另一个人知道用哪份文件、在哪个环境、点哪一步、看到什么，以及什么结果本来应该发生。
以下是构造的教学记录，示例日志、账号和次数都不是本站线上实测。它展示交付给开发者的证据形式，不提供真实用户文件。
先把预期行为写成可判定条件
测试需求 U17：已登录用户可上传单个 PNG/JPEG，文件不超过 10 MiB；符合尺寸与内容规则的文件应返回 201 并出现预览。10 MiB 在这里明确为 10×1024×1024 字节，不混用十进制 MB。
教学环境：应用 demo-build-17，测试账号 test-u17，Windows 测试机，同一浏览器配置、同一网络；浏览器准确版本应从实际运行环境抄到正式记录，不能把模板里的占位当已确认。没有变更环境时才把几次尝试放在同一对照组。
| 文件 ID | 格式 | 字节数 | 尺寸 | 独立解码检查 |
|---|---|---|---|---|
| P-small | PNG | 524,288 | 2048×2048 | 通过 |
| P-large | PNG | 6,291,456 | 2048×2048 | 通过 |
| J-large | JPEG | 6,291,456 | 2048×2048 | 通过 |
这些是教学样本属性。实际报告应附样本路径与 SHA-256，让同事拿到同一文件；若不能共享原图，应构造无敏感内容的替代文件并重新验证。两张 PNG 即使尺寸相同也不是只差“大小”的同一输入，编码与内容可能不同，所以结果仅支持大小相关的排查方向。
最短复现步骤
- 登录 test-u17，打开上传页，清空已有待上传项目。
- 选择 P-large，确认文件选择器只选一个文件。
- 点击上传，等当前请求结束；记录请求 ID 与时间。
- 重新进入相同初始状态，按同样步骤再试两次。
- 用 P-small、J-large 分别做同样三次，不在中间修改服务配置。
教学观察：
| 样本 | 尝试 | 网络结果 | 页面结果 |
|---|---|---|---|
| P-small | 3/3 | HTTP 201 | 出现预览 |
| P-large | 3/3 | HTTP 413 | “上传失败” |
| J-large | 3/3 | HTTP 413 | “上传失败” |
实际复现记录不应只写“三次都失败”，还应保存每一次请求。例如 P-large 第一次的教学摘要：
时间：2026-10-01T02:15:00Z
请求：POST /api/upload
请求 ID：demo-u17-p-large-01
文件字段：file
文件字节数：6291456
请求方式：multipart/form-data（请求总长包含边界与其他字段）
响应状态：413
响应体：{"error":"payload too large"}
页面提示：上传失败
预期：按 U17 接受该合法 6 MiB 文件并返回 201
不能把文件大小直接等同 HTTP 请求总长度。正式日志保存 Content-Type、实际请求大小和已脱敏响应，不保存会话 Cookie、Authorization 或他人的文件内容。
让 Codex 输出“证据支持到哪里”
根据本记录整理 issue.md：需求来源、环境、样本哈希、最短步骤、逐次结果、预期/实际差异。
原话与推断分开。没有实际浏览器版本、哈希或日志附件的字段标待补。
给出按优先级的验证计划；本轮不修改上传限制，不把 413 直接认定为某一层配置错误。
查项目中请求体限制的位置及单位，标明应用、代理、网关各自的证据来源。
若能读取测试环境日志，按请求 ID 对齐；不能访问则列缺失证据，不补造。
本组现象支持“较大请求被拒绝”的假设，而且 JPEG 对照说明不局限于 PNG。它不能证明限制一定是 5 MiB、一定来自反向代理，也不能排除账号、路由和其他校验的影响。下一步应检查各层限制与请求日志，再做接近阈值的额外样本；不能先放宽所有限制，把症状消失当成根因已证实。
复现记录完成的标准是别人能重复该现象并追到同一请求。修复是否成功是下一项任务，需要在原样本、边界样本和正常样本上重新运行，不能把“已稳定复现”写成“已修好”。
下一步
继续阅读与你当前问题相关的教程：
