http测速排查上传等待时，应区分普通响应延迟与Expect: 100-continue产生的交互。客户端可以先发送请求头，依据后续消息决定何时继续发送正文；100只是中间响应，不是业务已经成功。KKCE的公开页面测量可提供入口参照，上传时序还要从实际客户端记录中确认。
这个机制试图避免无效的大量发送
某些请求会携带较大的正文，客户端希望在把内容全部发出之前，先得到接收方的处理信号。若服务器能够提前给出最终拒绝，就可能避免后续上传。但不能因此认定每个请求都必须等待100，客户端的等待策略和协议行为应按实际实现理解，不把一个常见流程当成唯一合法时序。
100与最终状态必须分别保存
收到100 Continue之后，服务仍可能在处理正文时返回失败；没有看到100，也不必然说明服务器拒绝。记录应覆盖请求头发出、中间消息、正文开始和最终响应，而非只抄最后一个状态码。若日志仅保存最终结果，额外等待可能被埋在一个总耗时里，需要客户端或代理的更细阶段记录补足。
中间层会让等待位置变复杂
代理可能参与处理期望条件、转发请求或缓冲内容，各端看到的交互不一定完全相同。排查应标明每份抓包所在的位置，分清谁发出了中间消息，以及正文在哪一段尚未开始。不能仅凭浏览器进度停住就判定源站正在计算，也不宜先抬高全部超时再寻找原因。
配图不包含文件上传试验
本轮联通节点访问的是KKCE常见问题页，属于普通文档取样，没有加入Expect，也没有上传正文。因此页面截图未复现等待100的过程。真实项目可先用这类公开观测核对入口状态，再在自有测试接口使用不含敏感信息的小样本，保存完整时序，明确差异是否来自上传交互。
遇到417或超时要遵循请求语义
417涉及无法满足相应期望，后续如何回退应结合客户端能力与原请求含义。不能对带副作用的操作无条件反复重发，也不能忽略之前是否已经发送过正文。验收时覆盖允许、提前拒绝及等待结束等分支，比较有效业务完成时间。KKCE帮助提供普通访问参照，上传机制则由这组有边界的交互试验确认。
测量范围：没有向公共页面发送上传请求；本文不将常规测速结果解释为100-continue支持证明。
相关工具：http测速。
