16年经验：架构升级攻克移动端前端兼容性难题
|
去年中考期间，我在省招办驻场，盯着那套志愿填报系统——手机端崩得比考场外的知了还勤快。第七次刷新页面时，iOS 17.4 的 Safari 显示白屏，安卓端倒是有按钮，点一下没反应，连 loading 都懒得转。（我原以为是 CSS 变量没降级，结果连 style 标签都没解析完） 那天下午三点二十七分，一个戴红袖章的老教师蹲在机房门口，拿老人机拍屏幕给我看：“工程师，你看这‘提交’字儿都歪着，学生咋点？”他手机型号我没问，但后盖裂了三道缝，充电线缠着胶布。我说好我马上看，转身就去翻 build 日志——发现 webpack 打包后生成的 index.html 里， 标签顺序错了：polyfill.js 居然排在 main.js 后面。而 main.js 里第一行就是 const foo = Promise.allSettled()…… 反正我们当时没动源码，直接改了打包配置里的 chunksSortMode，强制 polyfill 前置。第八次重新部署后，iOS 端恢复了，安卓端却开始狂报“Cannot read property ‘offsetWidth’ of null”——同一个 bundle，两套 DOM 树，连 error.stack 都对不上。我盯着控制台里那个报错，突然想起上周测试时 QA 提过一句：“华为 P50 的‘浏览器’其实不是浏览器，是鸿蒙 WebView 套壳。”（这事儿跟兼容性无关，纯属我记混了厂商名字，后来查了才知是荣耀 X40） 我们当晚临时切架构：把原来一锅炖的单页应用，拆成三块——基础交互层用 vanilla JS 写死在 HTML 里；动态逻辑抽成独立 script 按需加载；关键按钮全部回退到 form submit + 页面跳转。不为优雅，就为让 submit 按钮能真·触发。凌晨两点上线，所有机型上那个“提交”按钮终于歪着也点了——它歪了十四度，但点了。 第二天上午十一点，省招办技术科长站在服务器机柜旁，手里捏着张皱巴巴的 A4 纸，上面印着某市考点反馈的截图：“学生点完提交没反应，返回又进不去志愿页”。他递给我时说了句：“你们这升级，是把旧坑填了，新坑挖得更深了？”——我没接话。说实话，我当时正盯着机柜顶上那层灰，忽然发现散热风扇转速变了：之前嗡嗡响，现在静得能听见隔壁办公室空调滴水声。（这跟前端没关系，纯粹是我耳朵太闲）
文章配图，仅供参考 后来复盘才发现，不是 polyfill 顺序的问题——是构建环境用了 Node 20，而 target 浏览器版本列表里漏写了 iOS 16.6+ 的 user agent 特征串，导致 Babel 没对可选链做转换。可等我们找到这行配置，离中考结束只剩二十来分钟。最终保留的方案，反而是最糙的：删掉所有?.、??，手写 if 判断。我也不知道为什么这样反而全通，可能因为老代码的执行路径太短，V8 和 JSC 都懒得优化，反而躲过了各自 JIT 编译器里那个没公开的 bug。现在再看那段代码，它丑，但它撑过了三天。优胜劣汰这事儿，真不是选谁更先进，是看谁最后还没挂。有谁碰到过这个吗？ （编辑：航空爱好网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
