每次升级模型都要重跑注入测试：我把这道关卡亲手搭了出来
我把注入回归测试跑在自己的 LLM 流水线上。朴素守卫 11 条只拦 2 条，结构化守卫全部拦下，重构漏掉的检测器也被关卡精准点出。
archive
专栏 · 第 4
356 · 第 4
WebMCP进入origin trial——provideContext为何半年就消失了
WebMCP以Chrome 149的origin trial正式落地，但二月介绍的那套API已经变了。navigator.modelContext迁到了document.modelContext，provideContext因安全问题被移除。本文以官方文档与规范Issue为依据，梳理现在该注册的工具形态与安全注解。
FAQ富媒体结果已经结束，但别急着删掉Q&A标记
Google在2026年5月7日彻底停用了FAQ富媒体结果。把FAQPage JSON-LD丢进离线校验器，schema能通过，可富媒体结果返回的是DEPRECATED。就在"通过"与"可见"分岔的这个点上，本文依据Google官方文档，梳理Web开发者现在该如何改代码和内容。
官方说「WebSocket 不再拦截 bfcache」，我重测了三次，次次都被拦
Chrome 149 宣布活动中的 WebSocket 不再阻止 bfcache。我在 Chrome 150 的三种环境里重新测了一遍，notRestoredReasons 照旧返回 websocket，三次都一样。发布说明和实测对不上的那个点，连同复现脚本、测量日志和三次运行的差异都一起记了下来。
aria-modal="true" 什么都没拦住：模态框焦点逃逸实测与 inert
一个带 role="dialog" 和 aria-modal="true" 的「标准」模态框，按第三次 Tab 时焦点就逃到了遮罩层背后，而 axe 报告的焦点类违规为 0。我把同一份标记分别换成 aria-hidden 和 inert，逐次记录键盘焦点的实际落点。
opens: "eleven" 三层校验全放行 — 餐厅营业时间 JSON-LD 的实测记录
给自己运营的餐厅推荐PWA补上Restaurant结构化数据：把按天存储的营业时间字符串转换成openingHoursSpecification，再把同样三个缺陷依次喂给类型检查、schema.org校验器和运行时门禁，逐层测量谁能抓住什么。并引用官方文档，诚实划清它对本地排名的作用边界。
unload被拦，beforeunload放行：bfcache实测六轮
「后退」能不能瞬间打开，不是口味问题，是可以量的。我做了六个页面，每个只埋一种阻断条件，逐一执行真实的后退导航，读取 pageshow.persisted 与 notRestoredReasons。unload 被拦，beforeunload 和 no-store 都放行了。
我的聚合 RSS 混着四种语言的 1,248 条，没有一条标了语言
W3C 在 2026-07-16 公开了字符串语言与方向元数据的首份草案。我照着它审计了自己的四语站点，发现聚合 RSS 的 1,248 条内容全是无标注输出。这里有实测、修复代码和防回归的构建关卡。
WCAG 2.2 最小目标尺寸：藏在92分绿灯背后的AA不合格
一排22×22的分页链接，拇指总按偏，Lighthouse却给了无障碍92分。我把WCAG 2.2新增的SC 2.5.8（最小24×24）种进沙箱，用自写脚本和Lighthouse各测一遍。自动工具如今能抓尺寸违规，却把例外判定甩回给你。连24px圆是否相交的间距例外计算，都用实测日志和CSS修复讲清楚。
决定 AI Overview 能否引用你页面的那一行 meta —— 实测 robots 摘要指令
一行 nosnippet 已经不只是关掉搜索摘要。Google 官方文档明确写道：这条指令还会阻止内容被用作 AI Overview、AI Mode 的输入。我做了一个坏页面和一个好页面，再写解析器逐一审计，测出 max-snippet 与 data-nosnippet 的真实效果，以及"最严格者胜"这条规则如何咬人。
一行 CSS 把强制布局从 27.3ms 压到 1.8ms：content-visibility 实测
同一份 HTML、同样的字节数，只多加一行 CSS，强制布局成本就降了 15 倍。我把一个 400 段的页面做了两个版本，用 Chrome 追踪和 Performance API 实测 content-visibility: auto 到底省了多少渲染，并讲清 contain-intrinsic-size 与无障碍陷阱。
点一下花了264ms — 同样的活儿切碎后只要56ms：一次INP实测
INP在2024年取代FID成为Core Web Vitals的响应性指标。我用Event Timing API直接测量同样220ms的工作在一口气跑完与用scheduler.yield切碎两种做法下的差异，并用代码和日志完整记录264ms(需改进)如何降到56ms(良好)的全过程。