在这行敲了快十年的代码，我经历过无数次让人血压飙升的线上事故。但如果你问我，哪个 Bug 最让人绝望？不是内存泄漏，不是请求竞态，而是那句让每一个前端工程师听了都会瞳孔地震的经典台词：
Chrome 上好好的，Safari 上却挂了😖。
你在 Chrome 上调好了一切。布局完美，动画流畅，接口正常。你信心满满地提交了代码，甚至在群里拍着胸脯说：已经自测通过。
然后 QA 拿着一台 iPhone 走过来，面无表情地把手机屏幕怼到你脸上。你看到了一个你从未见过的、完全无法理解的布局错乱，或者一个在 Chrome DevTools 里根本无法复现的白屏崩溃。
这不是你的代码有问题。这是 Safari，或者更准确地说，是 WebKit 引擎，在跟你过不去🫵。
这可不是 Bug，这是 Apple 的商业选择
很多人把 Safari 的各种奇葩表现归结为浏览器开发团队技术不行。这是一个巨大的误解。WebKit 团队的工程师水平绝对是世界一流的，但问题在于：他们的优先级，从来不是让 Web 应用变得更好。
你必须理解 Apple 的商业逻辑。Apple 的核心盈利模式是什么？是 App Store 的 30% 抽成。每一个在 App Store 里上架的 App，每产生一笔交易，Apple 都要从中抽走接近三分之一的利润。
而 Web 应用是什么？是绕过 App Store 的替代品。如果浏览器足够强大，强大到可以完美运行各种复杂应用，那开发者为什么还要花钱上架 App Store？用户为什么还要去下载原生 App？
所以，Apple 有极其强烈的商业动机，让 Safari 的 Web 能力恰好够用，但永远不够好🤷♂️。
你会发现一个极其诡异的规律：几乎每一个能让 Web 应用接近原生体验的关键 API，Safari 永远是最后一个支持的，而且支持得还磕磕绊绊。Web Push（网页推送通知）拖了整整 8 年 才在 iOS 上勉强支持；PWA（渐进式 Web 应用）的安装体验至今残缺不全；WebRTC 的实现充满了各种独家的兼容性地雷。
在 iPhone 上，所有浏览器都是 Safari
如果 Safari 的问题只存在于 Safari 本身，那你大可以告诉用户换个浏览器。但 Apple 做了一件更加霸道的事情：在 iOS 上，无论你下载的是 Chrome、Firefox 还是 Edge，它们的底层渲染引擎，全部被强制替换成了 WebKit。
没错，你在 iPhone 上打开的 Chrome，它只是披了一层 Google 皮肤的 Safari。所有的渲染、所有的 JavaScript 执行、所有的 CSS 解析，走的全是 WebKit 的管线。
这意味着什么？意味着当 WebKit 有一个 Bug，全球十几亿台 iPhone 上的所有浏览器都会同时中招，无一幸免。你的用户根本没有任何逃生通道。
虽然欧盟的《数字市场法案》（DMA）已经在推动 Apple 在欧洲地区开放第三方引擎，但在中国大陆市场，这个封锁在 2026 年依然铁板一块 😖
那些让前端集体破防的 Safari 经典深坑
说了这么多宏观层面的原因，下面咱们来扒一扒那些最经典、最让人崩溃的 Safari 独家 Bug。如果你是前端，下面这些场景你一定经历过至少三个👇。
100vh 问题
这可能是前端历史上被骂得最多的一个 Safari Bug。
在 Chrome 上，100vh 就是视口的 100% 高度，清清楚楚。但在移动端 Safari 上，100vh 的计算竟然包含了底部的地址栏和工具栏 。当用户滚动页面、地址栏自动收起后，页面的实际可视高度和 100vh 的值就产生了错位。
直接后果就是：你精心设计的全屏落地页，在 iPhone 上永远会有一截内容被底部工具栏遮住，用户看不到你的核心按钮。
这个问题折磨了全球前端无数年，直到后来 CSS 标准被迫新增了 dvh（动态视口高度）、svh（最小视口高度）和 lvh（最大视口高度）三个单位来补充。而这三个补丁单位的诞生，完全就是因为 Safari 一家的问题🤷♂️。
Date 构造函数
一行在全世界任何浏览器上都能正常运行的代码，唯独在 Safari 上直接返回 Invalid Date：
javascript
// 在 Chrome、Firefox、Edge 上完全正常
new Date('2026-08-17 15:30:00');
// 输出：Mon Aug 17 2026 15:30:00
// 在 Safari 上：直接崩溃
new Date('2026-08-17 15:30:00');
// 输出：Invalid Date原因极其荒唐：Safari 的 Date 解析器严格要求日期和时间之间必须用 T 分隔（即 2026-08-17T15:30:00），而不接受空格。这是一个极其微小的格式差异，但它足以让你的整个时间展示模块在所有苹果设备上全面瘫痪。
overflow: hidden 的失效
当你在 Safari 上给 body 设置 overflow: hidden 来禁止页面滚动（比如弹窗打开时锁定背景），你会发现页面依然可以被拖动。这是因为 Safari 有一个极其顽固的橡皮筋回弹效果，它在底层直接无视了你的 CSS 声明。
为了解决这个问题，前端不得不用 JavaScript 去监听 touchmove 事件并强行阻止默认行为，甚至需要在 body 上动态切换 position: fixed------一个 CSS 能解决的事情，在 Safari 上硬是被逼成了一套极其丑陋的 JS Hack。
Safe Area Inset 与刘海屏
自从 iPhone X 引入了刘海屏和底部的 Home Indicator 横条，Safari 就多了一套独家的 env(safe-area-inset-*) 环境变量。如果你的页面没有正确处理这些安全区域，你的底部导航栏就会和 Home Indicator 重叠，用户根本点不到最下面的按钮。
这套东西在其他任何浏览器上都不存在，是 Apple 硬件设计倒逼出来的纯前端适配成本。
你的用户，不会因为你讨厌 Safari 而改变
吐槽归吐槽，Safari 的市场份额摆在那里。全球将近 20% 的浏览器流量来自 WebKit，在国内的 iOS 用户群体中这个比例更高。你不可能放弃这些用户，所以你必须学会在 WebKit 里做妥协。
Safari 的问题，本质上不是技术问题，而是商业博弈的产物。只要 Apple 的 App Store 抽成模式不变，WebKit 对前沿 Web API 的战略性拖延就不会停止。
但话说回来，正是因为有 Safari 这种极其恶劣的宿主环境存在，才让前端工程师这个岗位不可能被简单地替代。AI 可以帮你生成一套在 Chrome 上完美运行的代码，但它绝对写不出那些只有被 Safari 毒打过无数次的老前端🫡。
好了，今天就分享到这里吧🙌
