第 1 章：H5 与网关验证概述
为什么你需要这门课？
做了快十年的 H5 开发，我踩过的坑至少能绕办公室三圈。最让我难忘的一次——一个看似简单的活动页，在 iOS Safari 上完美运行，结果在某个国产安卓浏览器的低端机型上，滑动卡成 PPT，付款按钮点十次才有反应。查了一整天，最后发现是网关侧的缓存策略和前端异步请求撞上了。
从那天起我就明白：H5 在手机上跑得顺畅，不等于在真实用户手里顺畅。中间隔着网关、CDN、运营商劫持、不同 WebView 的差异……随便一个环节出问题，用户体验就是崩塌式的。这门课就是把我这些年踩过的雷、验证过的套路、沉淀下来的检查清单，全部摊开给你看。
课程介绍：我们在讲什么？
这门课聚焦在两个核心域：多平台 H5 兼容性 和 网关交互兼容性。
- 多平台 H5 兼容性——不只是 iOS/Android。我还会带你覆盖小程序 WebView、企业微信内置浏览器、甚至智能电视和车载系统的 H5 环境。每个平台的渲染引擎、JavaScript 引擎、功能支持度都不一样，你需要一套系统的方法去兜住这些差异。
- 网关兼容验证——很多人把网关当黑盒。其实网关会在请求路径上做缓存、改写、限流甚至注入脚本。我曾经遇到过某省运营商在 HTTP 响应里插了一段广告 JS，直接导致页面白屏。网关验证就是要提前发现这些“看不见的中间人”问题。
说白了，这门课是一份从“前端写好代码”到“用户真正用好”的全程验证指南。我们不看理论空话，只讲实操：用什么工具测、测哪些点、遇到问题怎么定位、怎么修。
学习目标
学完这门课，我希望你能做到这几件事：
| 目标 | 对应的能力 |
|---|---|
| 构建多平台验证矩阵 | 能根据产品用户画像，列出需要覆盖的设备/浏览器/系统组合 |
| 设计网关兼容测试用例 | 能针对缓存、压缩、HTTP 头、重定向、劫持等场景写覆盖大纲 |
| 掌握 3 种主流调试工具链 | Chrome DevTools 远程调试、Whistle/Charles 代理抓包、vConsole 真机日志 |
| 快速定位跨界问题 | 5 分钟内判断故障在前端、网关还是网络层 |
| 输出有效验证报告 | 能写出让开发和运维都看懂的兼容性报告，附复现步骤和设备信息 |
适用人群
这门课不是给零基础看的。如果你符合下面任意一类，效果最好：
- 中级及以上 H5 前端工程师——已经写过不少页面，但经常碰到“发版后线上出兼容问题”的困局，想系统性地把验证能力补齐。
- 移动端测试 / QA——你正在从功能测试转向兼容性测试，或者需要搭建本团队的兼容验证流程。
- 前端架构师 / 技术负责人——你需要制定团队的验证规范，或者对线上质量负责，想参考一套经过实战的方法论。
- 运维 / 网关侧工程师——负责网关配置或 CDN 调优，想了解前端视角下网关的行为影响。
如果你刚入行不到一年，建议先吃透 H5 基础（DOM、CSS、网络请求）再来，否则有些调试操作会不清楚为什么要这么做。
知识体系：一张图看清全貌
下面这张图把本章涉及的核心模块串起来了。你可以先扫一眼，后面每个模块会展开来讲。
我个人的习惯：每接手一个新项目，我会先把上图中的三个分支按优先级排个序。如果产品以 iOS 为主用户，我就会先测 Safari 和 WKWebView，再快速覆盖安卓头部机型。网关方面重点看缓存策略——你想想看，90% 的线上 H5 白屏和样式异常其实都和缓存过期时间设置不当有关。
验证到底有多重要？一个真实案例
去年我帮一家电商团队做兼容审计。他们的活动页在线上挂了三天，运营一直在背锅。后来定位发现：网关把服务端返回的 Set-Cookie 头给去掉了，导致前端维持登录态的请求每次都返回 302 到登录页。这个问题的根源是网关侧的“安全规则”过度过滤了。
当时开发问：为什么测试环境没发现？因为测试环境不走那个网关。这就是典型的验证盲区——你测了前端，也测了后端，但没测两端之间的那一层。