H5应用加固前如何梳理静态资源CDN
如果我要给H5应用做加固，为什么不能直接开始改代码或上安全方案，而是要先检查静态资源的CDN配置？
先梳理CDN配置，能避免加固后资源失效
在H5应用加固前梳理静态资源CDN配置，是为了提前确认脚本、样式、图片、字体等资源的实际加载路径和依赖关系。加固过程常会涉及文件改名、签名校验、资源替换或访问控制调整，如果不先理清CDN来源，容易出现页面白屏、样式丢失、脚本加载失败或缓存命中异常等问题。通过梳理CDN，还能发现是否存在多套域名、历史旧链路、跨域配置不一致等情况，便于在加固方案里一起处理。
我想在加固前把静态资源的CDN摸清楚，具体应该关注哪些信息，才算比较完整？
重点看资源清单、域名、缓存和回源路径
梳理时建议重点检查四类内容：一是静态资源清单，包括 JS、CSS、图片、字体、音视频等是否都已覆盖；二是CDN域名和路径，确认生产、测试、灰度环境是否使用不同配置；三是缓存策略，查看缓存时间、刷新规则、版本号或文件指纹是否统一；四是回源路径和跨域设置，确认源站地址、HTTPS证书、CORS规则、Referer防盗链等是否符合加固要求。把这些信息整理清楚，后续做资源保护或访问控制时会更顺畅。
如果静态资源本来就已经走CDN了，做H5加固时还会有哪些容易被忽略的问题？
常见风险是缓存、引用和版本同步问题
即使静态资源已经使用CDN，加固时依然可能出现风险。常见情况包括：CDN缓存未及时刷新，导致新包上线后用户仍然拿到旧资源；页面中存在硬编码资源地址，切换加固策略后引用失效；不同环境的资源版本未同步，造成线上线下表现不一致；部分第三方资源未纳入统一管理，埋下安全和稳定性隐患。加固前把这些风险逐项排查出来，可以减少上线后的回滚概率。
我怎么知道当前的CDN资源结构适不适合做加固，哪些情况说明需要提前改造？
当资源分散、命名混乱或依赖不清时就该改造
如果你的静态资源分布在多个域名或多个存储位置，文件命名没有版本标识，页面引用方式比较混乱，或者资源更新完全依赖人工改链接，这些都说明在加固前需要做CDN资源改造。比较理想的状态是资源有统一的命名规范、明确的版本管理方式、可追踪的发布流程，以及可验证的回源与缓存机制。只要现有结构无法支撑这些要求，就应该在加固前完成整理和改造，避免后续安全策略和发布机制互相冲突。