CDN后的脚本下载不完整：压缩响应与Content-Length怎样核对

网页空白、控制台提示脚本解析失败，有时并不是脚本代码写错，而是浏览器收到的内容与预期不同。CDN之后多了压缩、缓存或错误页面处理，排查时需要同时看响应头和实际正文，不能只看请求是否返回200。

先确认浏览器究竟收到了什么

在开发者工具中选中失败资源，记录URL、状态码、响应类型、内容编码与缓存信息，再查看正文开头。若脚本地址返回的是登录页面或HTML错误提示，应先查路由、鉴权和错误响应处理，而不是调压缩级别。

Chrome网络面板文档说明了查看请求、响应和传输信息的方法。导出记录前要清除凭据及个人数据；给支持人员的证据应尽量限于公开测试资源。

比较大小之前先统一口径

HTTP语义规范用Content-Encoding描述表示内容采用的编码。对普通携带响应体的压缩资源，编码后传输的内容大小与解压后的文件大小不同，不能直接把两者相减就认定丢包。没有Content-Length也不自动说明响应不完整，应结合协议及实际结束情况判断。

用一个资源建立最小对照

选取能稳定复现的公开脚本，保存部署版本和可信校验值。对比正常与异常请求的编码、内容类型、完整正文校验结果和发生时间。若链路允许，应由维护人员在受控路径观察源站实际输出，避免为排障临时公开源站入口。

如果同一版本仅某种编码失败，检查是否重复压缩、错误标记编码，或某一层改写正文后未同步元数据。若内容在固定位置截断，继续观察应用退出、代理超时与连接结束记录。每个假设都应对应一项证据，不能只依据文件“看起来短了”。

修复要覆盖缓存中的异常副本

源站配置修好后，边缘可能仍保留旧响应。先在可控路径验证新响应正确，再按实际受影响的URL和变体清理缓存。保留原异常样本及配置差异，避免连续刷新把证据完全抹掉。

不要为了让一个脚本加载成功而长期关闭全站压缩，也不要同时修改路由、缓存和编码多个条件，否则很难确认真正原因。若需要临时绕开某项处理，应限制范围并记录撤销时间。

恢复验收看结果而不只看状态码

检查受影响页面能完成主要功能，资源正文与发布包对应，正常和异常路径都不再返回混淆内容。再复测首次访问和缓存命中后的访问，确认问题没有被一次缓存绕过掩盖。

接入CDN与安全加速时，把资源编码和发布版本纳入交接材料；涉及多层旧副本时，可配合缓存更新排查缩小范围。

资料核对日期：2026年10月30日。本文由AI辅助整理，技术事实依据文内原始资料核对。示例与操作清单供实施参考；产品配置和软件维护状态以实施时的官方资料为准。