H5应用加固前如何确定页面完整性校验方式
在准备做H5应用加固时，我应该从哪些维度去选择页面完整性校验方式？不同业务场景下，怎么判断是适合做文件哈希校验、资源签名校验，还是运行时校验？
从业务风险、发布方式和性能要求来选
可以先看页面的敏感程度和篡改风险，再结合发布模式与性能开销来判断。静态资源较多、版本发布相对规范的场景，通常更适合文件哈希或资源签名校验；对运行时篡改风险更敏感的场景，可以考虑在页面加载和关键脚本执行阶段做完整性检查。若业务对首屏性能要求较高，就要避免过重的校验逻辑，优先选择轻量、可缓存、可增量验证的方案。
如果我要给H5应用做加固，是否应该在设计阶段就明确哪些页面、脚本、静态资源需要纳入完整性校验？如果范围定得不合理，会带来哪些问题？
需要提前定义，避免漏检或过度校验
建议在加固前就明确校验范围，因为范围会直接影响安全效果和实现成本。若范围过小，关键页面或核心脚本可能没有被覆盖，篡改后难以及时发现；若范围过大，校验逻辑会增加加载耗时，也可能让维护复杂度上升。比较稳妥的做法是优先覆盖核心业务页面、敏感脚本、配置文件和关键接口依赖资源，再根据风险等级逐步扩展。
在确定H5页面完整性校验方式时，我既想保证安全，又担心会影响页面加载速度和用户体验。有什么办法可以提前评估这种影响？
通过测试校验开销和加载链路来评估
可以在设计阶段做性能评估，重点关注校验逻辑是否会阻塞首屏渲染、是否增加额外请求、是否占用过多CPU资源。建议在真实网络环境下测试不同校验方式的耗时，并观察对首屏时间、交互响应和异常重试的影响。若影响明显，可以把校验放到非阻塞阶段，或采用分层校验、缓存校验结果、按需校验等方式降低体验损耗。
如果H5页面在加固后发现内容被改动，完整性校验通常应该怎么处理？是直接阻断访问、给出提示页，还是仅记录日志并上报？
根据业务重要性决定处置级别
处理方式应结合业务风险来定。对核心交易、登录、支付等高风险页面，发现异常时可以直接阻断访问并跳转到告警页；对一般展示类页面，可以先记录日志、上报风控平台，再根据风险等级决定是否限制访问。无论采用哪种方式，都建议保留完整的异常信息，便于定位被篡改位置、分析攻击路径，并持续优化校验策略。