查个成绩都这么难？记一次 iPhone Safari 弹窗拦截的排查过程

为什么同一个网页，电脑能点击跳转，iPhone 却毫无反应？—— 一次 Safari 弹窗拦截的排查记录

背景

最近刚结束上海交通大学博士研究生的复试，在等待结果的过程中，想通过学校研招网查看往年的拟录取名单作为参考。

名单公示的地址是：https://ga.sjtu.edu.cn/zsgl/lqgl/nlqmdgs_bs.aspx

在电脑上打开一切正常，页面显示各个学院的列表，点击任意学院旁边的"查看"按钮，就会弹出新窗口显示该学院的详细名单。

但当我用 iPhone 打开同一个链接时，问题出现了：点击"查看"按钮后，页面只是闪烁了一下，然后停留在原地，根本不会跳转到具体学院的页面。反复尝试多次，结果都一样。

这让我产生了好奇：同样的网页、同样的操作，为什么电脑可以，手机就不行？

解决问题

既然问题只出现在 iPhone 上，我决定从 iOS Safari 的特性入手排查。

首先想到的是 Safari 的弹窗拦截功能。很多老旧的网站喜欢用 JavaScript 的 window.open() 来打开新页面，而现代浏览器出于安全考虑，会对这种行为进行限制。

于是我做了一个简单的测试：

结果：问题解决了，新窗口正常弹出。

分析原因

问题虽然解决了，但我想搞清楚背后的技术原理。于是我查看了这个页面的源代码，发现了一些有意思的细节。

源码分析："查看"按钮是怎么工作的？

查看页面源码，"查看"按钮的 HTML 结构如下：

<form method="post" action="./nlqmdgs_bs.aspx" id="Form1">
<!– 隐藏字段：__VIEWSTATE, __EVENTTARGET 等 –>
…
<input type="submit" name="dgData$ctl02$btncx" value="查 看"
onclick="this.Form1.target='fsmdgscx_bs.aspx';" />
</form>

这是一个典型的 ASP.NET WebForms 页面。点击按钮时发生了什么？

关键点：这里的"新建窗口"行为，在浏览器看来就是一个 Pop-up（弹窗）。

疑问一：为什么电脑端没问题，手机端就被拦截？

电脑端浏览器（Chrome、Edge、桌面版 Safari）在拦截弹窗时，通常会在地址栏附近显示一个小图标或提示条，告诉用户"有弹窗被拦截，是否允许？"。用户看到提示后可以选择放行。

但 iOS Safari 的策略更加激进：它默认静默拦截弹窗请求，不给用户任何视觉反馈。从用户的角度看，就是"我点了按钮，但什么都没发生"，甚至会怀疑是不是按钮坏了。

疑问二：为什么点击后页面会"闪一下"？

这个现象其实可以从源码中找到答案。

当你点击"查看"按钮时：

所以你看到的"闪一下"，其实是 PostBack 引起的页面状态更新，而真正应该打开的新窗口被 Safari 拦截了。

疑问三：为什么新窗口的 URL 和原页面一样？

在电脑端成功打开新窗口后，我注意到一个细节：新窗口的 URL 和原页面完全相同，都是 nlqmdgs_bs.aspx。既然地址一样，服务器是怎么知道要返回哪个学院的数据呢？

答案就藏在表单的隐藏字段里：

<input type="hidden" name="__VIEWSTATE" value="…" />
<input type="hidden" name="__EVENTTARGET" value="" />
<input type="hidden" name="__EVENTARGUMENT" value="" />

这是 ASP.NET WebForms 的核心机制：

• __VIEWSTATE：保存了页面的完整状态（包括你选择的年度、批次等）
• __EVENTTARGET：标识了触发提交的控件（哪个学院的"查看"按钮）

当表单以 POST 方式提交时，这些隐藏字段会随表单数据一起发送。服务器根据这些信息就能知道用户点击的是哪个学院，然后返回对应的名单。

这就是为什么 URL 相同但内容不同——决定内容的不是 URL，而是 POST 请求体中的数据。

疑问四：为什么刷新页面后会回到学院列表？

这是一个很有意思的现象：当你成功打开某个学院的名单页面后，如果按 F5 刷新，页面会"跳回"到学院列表，而不是继续显示刚才的名单。

原因同样与 POST 请求有关：

简单来说：页面的状态存储在 POST 请求中，而不是 URL 中。刷新时 POST 数据丢失，服务器无法知道你之前看的是哪个学院。

这也是为什么你无法通过复制 URL 把某个学院的名单分享给别人——因为 URL 本身不包含任何学院信息。

验证猜想

为了验证"弹窗拦截"确实是根本原因，我做了以下对照实验：

实验结果与分析一致：iOS Safari 的静默弹窗拦截是导致问题的直接原因。

"桌面模式"没有解决问题，这说明问题不在于网站的移动端适配，而是 Safari 浏览器的安全策略。

技术总结

通过这次排查，我对这个页面的工作机制有了完整的理解：

用户点击"查看"按钮
↓
onclick 事件：设置 form.target = 'fsmdgscx_bs.aspx'
↓
表单提交：POST 到 nlqmdgs_bs.aspx，携带 __VIEWSTATE 等隐藏字段
↓
浏览器尝试在新窗口打开响应内容
↓
┌─────────────────────────────────────┐
│ Safari 弹窗拦截开启？ │
│ ├─ 是 → 静默拦截，页面闪烁后无反应 │
│ └─ 否 → 新窗口正常打开，显示名单 │
└─────────────────────────────────────┘

写在最后

iOS Safari 的"静默拦截"策略本意是保护用户免受广告弹窗的骚扰，但也误伤了一些正常功能——尤其是像高校教务系统这类使用较老技术栈（ASP.NET WebForms）的网站。

如果你也遇到过"电脑能用，手机不行"的情况，不妨检查一下 Safari 的弹窗设置：

设置 → Safari 浏览器 → 关闭「阻止弹出式窗口」

问题也许就迎刃而解了。