用浏览器窗口玩贪吃蛇？看似无聊的游戏背后竟藏着实用的网页检查术

“我最近是安静了点儿，但别担心，我可没忘了你们有多喜欢在网上看到那些蠢到极点的点子。”独立开发者 Graham 在他的最新博文里这么开场，接着就亮出了一个让人眼睛疼、让电脑风扇狂转的玩意儿——用浏览器窗口本身作为像素块来渲染贪吃蛇。不是 canvas，不是 div 拼图，是几十上百个真实浏览器窗口，按游戏坐标排布、随蛇的移动而重新定位，在桌面上直接演出一场窗口级动画。

整个东西的起点，是一次同事间关于“你知道可以从一个浏览器窗口控制另一个窗口吗”的闲聊。当时他们讨论的还是个正经需求：检查第三方网站的坏链，然后逐个确认修复效果，同时避开 iframe 带来的各种限制。然而，当这个“跨窗口控制”能力落入一个喜欢折腾无用点子的人手里，就迅速滑向了一个深渊问题：既然能控制一个窗口，为什么不能控制一堆窗口？

于是，贪吃蛇——浏览器窗口版，就这么出现了。操作方式简单得出奇：按下“Start Game”，浏览器弹出权限请求，一次性给“总是允许弹窗”放行，接下来就只有方向键的事了。开发者的严格要求是“别点任何东西，只用方向键”，并在游戏结束后提醒玩家务必在计分窗口里点“关闭所有窗口”，否则等待你的就是手动逐个关闭几十个散落桌面的小窗口，场面会非常狼狈。游戏只在 Windows 的 Chrome 上做过测试，其他操作系统或浏览器组合能不能跑，作者留了一句“祝你好运”。

在技术实现上，这种失控玩法靠的是浏览器对弹窗窗口的精细操控能力。只要有一次真实的用户交互作为起点，再配合用户授权弹窗权限，脚本就可以用 window.open 指定每个窗口的宽度、高度、屏幕坐标，还能给每个窗口起一个唯一的名字，后续通过名字引用，在规定位置动态移动。窗口最小尺寸存在平台级别的限制，但对于贪吃蛇这类网格游戏来说，用一个个迷你窗口构成蛇身和游戏区域，刚好踩在能玩与足够折磨人的边界上。

游戏画面只能用“精神污染”来形容。贪吃蛇的每一节身体都是一个独立的浏览器窗口，窗口里渲染着对应像素的颜色；蛇移动时，几十个窗口同步调整位置，桌面上窗口标题栏、边缘和操作系统装饰无死角地挤在一起，形成一种既像素又溢出框架的怪诞美感。作者贴出的截图里，任务栏堆满了一排排小窗口图标，视觉效果远远超过传统网页游戏的范畴，更像是某种行为艺术。评论区已经有玩家跃跃欲试，准备截图晒分，同时也有人担心自己的内存条还撑不撑得住。

在所有人都被这个荒唐游戏笑得停不下来之后，作者笔锋一转，决定“来点正经的”。正是把这些窗口控制能力用在合理的地方，才让它从一个笑话翻回现实，成为解决实际工程问题的路径。他们的真实用例是：替工作项目检查第三方网站中的坏链，而这件事的复杂性在于，单纯依靠 HTTP 状态码远远不够。很多现代网站采用单页应用（SPA）架构，即便页面内容已经变成一片空白或者报错，服务器仍然会返回 200 状态码，让传统爬虫式检查完全失效。更头疼的是，有些目标页面躲在付费墙后面，虽然页面本身可以被访问到、返回 200，但付费墙之下的内容是否还存在、是否真的能正常加载，光靠服务器响应是看不出来的。

他们想要的是一个可以直观检查的队列工具：把一批待核查的第三方链接放进列表，逐个点开，人眼确认页面是否正常、是否需要登录、内容是否还在。如果把这个工具做成单窗口页面，最直接的办法就是套一个 iframe，在列表下方加载目标链接。问题在于，大量的第三方站点早已做了 iframe 防御——它们可以在服务端或前端设置 X-Frame-Options 或者 Content-Security-Policy，禁止自己的页面被别的网站“框”进 iframe 里展示。一旦限制生效，整个检查流程会瞬间被掐断。

于是，窗口操控就成了绕过 iframe 限制的坚固方案。他们的做法是打开两个浏览器窗口，左边一个较细长的窗口，固定显示待检查的链接列表；右边一个更大的窗口，专门用来加载当前被点击的链接目标页面。当操作者在左边列表里点下一个链接，脚本就通过窗口名精准控制右边窗口，让它导航到对应 URL，而不是在左边窗口的内部嵌套 iframe。这样一来，右边的目标页面就是在自己独立的浏览器窗体内正常加载的，不受任何跨域或防嵌策略的干扰。只要在左边窗口里维护一个检查队列，并且在右边窗口里完成人工确认，就可以顺利推进整张坏链清单。

更进一步，这种基于多窗口的协作模式还能承载登录态的场景。右边窗口加载的是第三方页面的完整环境，cookie、session、本地认证都天然存在，检查人员可以直接在右侧窗口里登录需要账号的付费墙后台、模拟用户行为，确认页面内容是否完整可用。这种操作在单窗口 iframe 方案里很难做到，不仅因为防嵌限制，也因为跨域策略会让 iframe 内的登录态变得异常脆弱，甚至触发安全拦截。

对比下来，这个原本被当成“蠢点子”的游戏项目，恰恰是对浏览器窗口能力边界的一次暴力测试。整个过程中，开发者其实只动用了两个关键能力：窗口定位与命名引用。但正是把这两个看似简单的点推到极致——定义尺寸、批量生成、按游戏节奏高频移动——才暴露了这些 API 在认真场景下能解决的实际问题。换句话说，贪吃蛇窗口版的真正价值，不是游戏本身，而是它作为一个极端压力测试，逼迫人们重新审视“可以控制另一个窗口”这件事到底能做成什么。

在博文的结尾，作者并没有给出什么行业大势的判断，只是很务实地说，希望这个窗口队列演示能给别人提供一点灵感。对于同样需要人工核查第三方内容的团队来说，左右双窗口加上精确的窗口引用，用几十行脚本就能搭出一个相当鲁棒的检查环境，成本远低于定制爬虫或浏览器插件。而回到那个游戏本身，它可能最大的贡献就是让一群开发者一边笑着关掉几十个弹窗，一边在心里默默记下了：下次再在项目中遇到 iframe 被禁、跨域受限的坑，或许还可以试试直接打开一个独立的窗口。