H5应用加固前如何确定资源完整性校验方式
在准备对 H5 应用进行加固时，如果不提前确认资源完整性校验方式，可能会影响页面加载、离线资源更新、缓存策略以及加固后的异常排查。如何在不影响用户体验的前提下，选择合适的完整性校验思路？
提前规划校验方案可以降低加固后的兼容风险
在加固前明确资源完整性校验方案，能够帮助你判断哪些静态资源需要校验、校验粒度应该到文件级还是目录级，以及是否会与现有缓存机制冲突。常见做法包括基于文件哈希、签名校验、清单比对等方式。选择时要结合 H5 的更新频率、资源体量、离线能力和加固后运行环境，避免因校验过重导致加载变慢，或因校验过弱导致资源被篡改而无法及时发现。
如果 H5 页面包含大量 JS、CSS、图片和字体资源，应该通过单文件哈希校验，还是通过资源清单统一校验更合适？不同方案在维护成本和安全性上有什么差别？
根据资源规模和更新频率选择更合适的校验粒度
单文件哈希适合资源相对稳定、需要精确识别每个文件是否被改动的场景，安全性更直观，但维护成本较高。清单校验更适合资源较多、更新较频繁的 H5 应用，它可以通过预生成的资源列表统一核对版本一致性，便于发布和回滚。若你的应用依赖 CDN、动态加载模块或分包机制，还要确认清单生成时是否能覆盖所有运行时可能请求到的资源。
H5 应用在浏览器缓存、Service Worker 缓存或本地离线缓存存在的情况下，资源完整性校验有可能拿到旧文件。加固前应该怎样设计校验逻辑，才能减少缓存干扰？
需要把缓存策略与校验机制一起设计
当 H5 应用存在多层缓存时，完整性校验不能只依赖客户端当前拿到的文件内容，还要结合版本号、资源指纹或服务端下发的校验清单进行比对。你可以在发布时为静态资源加入内容哈希，配合失效策略，避免旧缓存被误认为是最新资源。对于离线场景，还应明确缓存更新触发时机，并在校验失败时提供可恢复机制，例如重新拉取资源或切换到备用版本。
有些 H5 页面会按需加载脚本、样式或业务模块，这类动态资源在加固前不一定能一次性列全。如何确定哪些资源需要纳入完整性校验，哪些可以由运行时处理？
动态资源要结合加载入口和依赖关系进行覆盖
对于动态加载资源，校验范围应从主入口文件向外延伸，结合依赖树、路由配置和运行时加载规则一起梳理。凡是会影响核心业务流程的脚本、样式和关键配置文件，建议纳入完整性校验；非关键的图片、埋点或可降级资源，可以根据业务容忍度决定是否校验。为了减少遗漏，发布前应生成完整资源清单，并在测试环境中模拟不同网络和缓存状态，验证校验逻辑是否能覆盖真实运行路径。