Playwright POST 崩溃

APIRequestContext.post() 发出较大的请求体，服务端提前返回 413 或 429 并关闭连接，测试进程却被 write ECONNRESET 终止，外层 try/catch 没有接住。先区分 HTTP 拒绝与请求 socket 的未处理错误：这里不一定是业务请求的 Promise 正常拒绝。

这组表现出现在 Playwright 1.62.0、Node 22.19.0、Linux 的提前拒绝场景。正式 1.63.0 的请求实现已处理相应 socket 错误，当前 1.64.0 也应沿已修复的接口核对。并不是所有 ECONNRESET 都由同一原因产生。

响应已经到达，请求体仍可能在写入

上传过大或被限流时，服务端可以在没有读完整个请求体之前决定拒绝。客户端收到响应后，仍在写入请求 socket，连接被关闭就可能报错。

受影响实现没有正确覆盖这条 socket 错误路径，结果可能是未处理的 error 事件使整个进程退出，也可能表现为状态码已能读取，随后消费响应正文失败。给 post() 外面再套一层 try/catch，并不会替缺少监听器的 socket 建立错误处理。

保留第一条错误及对应操作阶段，确认使用的是 Playwright 的 APIRequestContext，而不是浏览器页面中的 fetch。核对服务端是否提前拒绝、返回了什么状态，以及响应正文是否完整；首次连接失败、空闲连接复用与普通服务端断连要分别判断。

先修复请求实现，再保留拒绝的含义

使用项目既有的包管理器与版本约束，选择兼容的正式 Playwright 1.63.0 或之后版本。核对实际安装的 @playwright/test、playwright 与相关核心包，不靠另一份全局版本判断测试运行器已更新。

已核对的实现会监听 socket 错误，并区分响应是否已经开始。响应到达后的特定网络连接错误，不再作为无监听器的错误向进程抛出；响应正文的读取和完整性仍由正常请求流程处理。不能因此承诺每次被重置的连接都能返回完整 JSON。

默认 failOnStatusCode 为 false，HTTP 413、429 等状态会返回响应对象。应用需要自行检查状态与正文；设置为 true 可以改变非 2xx、3xx 的处理方式，但它不是旧 socket 监听缺陷的修复。

也不要让代理把不完整响应改成 200，或者注册一个全局异常处理器后继续把测试判成成功。请求被拒绝，仍应该按接口约定被判定为拒绝。

maxRetries 不处理 HTTP 413 或 429

maxRetries 默认是零。它针对支持的网络错误重试，目前是 ECONNRESET，不按 HTTP 响应码重试。提高这个值既不能替代旧实现的监听修复，也不会自动理解服务端 429 的重试策略。

POST 可能包含创建、提交或其他副作用。客户端报连接错误，不证明服务端尚未执行操作；重试需要接口实际提供的幂等或结果确认契约。这里只需要验证原来的提前拒绝路径，无须反复向业务写入端点发送大请求。

在获准的测试端点上沿原场景验收：拒绝状态仍正确，完整正文可以正常读取，确实不完整的传输明确失败，进程不再因这条未处理 socket 错误退出。正常上传也应继续完成，响应资源沿原流程释放。一次状态读取成功，不能代替完整响应与测试结果的检查。