手机网页界面优化调研（mobile web，非原生 App）

调研日期：2026-09-21 服务对象：营销+留资型官网（首页七屏滚动动效、门店页、团餐页、订场页、六张留资表单、顶部导航六页签带下拉、汉堡断点 1099px）

说明：以下结论均由 4 个并行调研 agent 使用 WebSearch/WebFetch 实际检索核实，网页内容一律当数据处理。凡标注「未核实」的条目，是 agent 未能打开原文正文（多为 JS 渲染页面，如 Apple HIG / Material Design 官网），仅有多方二手来源互相印证；请在正式落地前自行人工确认一次官方原文措辞。凡标注「未找到 2023 年后的复核」的条目，结论本身可能仍成立，但没有找到更新的复核文章，落地时留意浏览器/规范是否有新变化。

一、触控（Touch Targets）

1. 结论：Apple HIG 建议交互控件最小可点击热区为 44×44pt，visionOS 平台例外为 60×60pt；视觉图标可以更小，靠内边距把热区补到 44pt。 怎么做： css .icon-btn{min-width:44px;min-height:44px;display:inline-flex;align-items:center;justify-content:center} .icon-btn svg{width:20px;height:20px} 出处：Apple HIG「Buttons」https://developer.apple.com/design/human-interface-guidelines/buttons （JS 渲染，未核实，多个独立二手来源如 LogRocket 一致转述同一原文措辞 "A button needs a hit region of at least 44×44 pt"）。

2. 结论：Material Design 3 建议触控目标最小 48×48dp（约合 9mm 物理尺寸），相邻目标间距建议 ≥8dp；可视元素可小于此值，靠透明热区撑满。 怎么做： css .icon-btn{min-width:48px;min-height:48px} .icon-btn+.icon-btn{margin-left:8px} 出处：Material Design 3「Structure」https://m3.material.io/foundations/designing/structure （JS 渲染，未核实，Android 官方无障碍帮助页 support.google.com/accessibility/android/answer/7101858 等多方转述互相印证）。

3. 结论：WCAG 2.2 SC 2.5.8 Target Size (Minimum)，等级 AA：指针目标区域须 ≥24×24 CSS px，除非满足五个例外之一——Spacing（以 24px 直径圆心判定不与相邻目标相交）、Equivalent（页面上有等效的满尺寸控件）、Inline（目标处于文本行内，受行高约束）、User Agent Control（尺寸由用户代理决定、作者未修改）、Essential（特定呈现方式是信息传达所必需或法定要求）。 怎么做： css a.inline-link{/* 行内文字链接，命中 Inline 例外，可不受 24px 约束 */} .icon-btn{min-width:24px;min-height:24px} 出处：W3C WCAG 2.2 Understanding 2.5.8，https://w3c.github.io/wcag/understanding/target-size-minimum.html （已核实原文，2023 发布，规范类文档持续有效）。

4. 结论：WCAG 2.2 SC 2.5.5 Target Size (Enhanced)，等级 AAA（更严格）：指针目标须 ≥44×44 CSS px，例外四条——Equivalent、Inline（句子/文本块中）、User Agent Control、Essential（比 2.5.8 少了 Spacing 例外）。 怎么做：核心 CTA（如"立即预约""提交"）直接按 44px 起做，不依赖例外条款。 css .cta-primary{min-height:44px;padding:0 20px} 出处：W3C WCAG 2.2 Understanding 2.5.5，https://w3c.github.io/wcag/understanding/target-size-enhanced.html （已核实原文）。

5. 结论：拇指热区研究的原始出处是 Steven Hoober 2013 年 UXmatters 文章《How Do Users Really Hold Mobile Devices?》：观察 1333 人次，49% 单手持握（其中 67% 用右手拇指）；但 Hoober 本人在原文明确承认，那张常被转载的"绿黄红热区图"只是"基于同事的小规模非正式取样"，属于"粗略而模糊（coarse and vague）"的示意，并非严谨量化研究。该"热区图"本身在网上流传已明显失真。 怎么做：页面顶部导航/关闭按钮等难触达区域适当加大热区和间距；底部固定操作栏用常规 44px 即可。 css .top-nav .icon-btn{min-width:44px;min-height:44px;padding:12px} 出处：原始研究 https://www.uxmatters.com/mt/archives/2013/02/how-do-users-really-hold-mobile-devices.php （2013，已核实原文含 "coarse and vague" 原话）；2024 年仍在引用具体数字的复核性文章 Ahmad Shadeed https://ishadeed.com/article/target-size/ （2024-01-10，已核实）。那张广泛流传的"热区分布图"未找到 2023 年后的专门复核，视为可能过时（Hoober 本人从一开始就承认其粗糙性，建议不要拿它当精确设计依据）。

6. 结论：触屏上的"粘滞悬停（sticky hover）"问题——手指划过元素触发 :hover 但没有"移出"事件清除它，导致高亮态卡住；标准做法是把悬停态包进 @media (hover: hover) and (pointer: fine)，让触屏设备直接跳过这段样式。 怎么做： css @media (hover: hover) and (pointer: fine) { .card:hover { transform: translateY(-2px); } } 出处：MDN @media/hover https://developer.mozilla.org/en-US/docs/Web/CSS/@media/hover 与 @media/pointer https://developer.mozilla.org/en-US/docs/Web/CSS/@media/pointer （已核实）；问题成因与修法见 CSS-Tricks《Solving Sticky Hover States With @media (hover: hover)》 https://css-tricks.com/solving-sticky-hover-states-with-media-hover-hover/ （2020-02-18，已核实）。

7. 结论：:active 表示元素被激活的瞬间（按下反馈），触屏可用于按钮按下态；:focus-visible 由浏览器启发式判断是否显示焦点环——键盘导航会显示，鼠标/触屏点击通常不显示，避免触屏点按后残留不必要的焦点框同时保留键盘可达性。 怎么做： css .btn:active{transform:scale(0.97)} .btn:focus-visible{outline:2px solid #2563eb;outline-offset:2px} 出处：MDN :active https://developer.mozilla.org/en-US/docs/Web/CSS/:active 、:focus-visible https://developer.mozilla.org/en-US/docs/Web/CSS/:focus-visible （已核实）。

8. 结论：作为 2023 年后的复核信源，Smashing Magazine 重申"所有目标至少 44×44px"（对齐 WCAG AAA 口径），正文内小图标/链接可放宽到约 27×27px，但屏幕边缘（顶部/底部）应更大——说明 2023 年后这组尺寸数字仍未被推翻。 怎么做： css .body-link-icon{min-width:27px;min-height:27px} .top-nav .icon-btn,.bottom-bar .icon-btn{min-width:44px;min-height:44px} 出处：Smashing Magazine《Accessible Target Sizes Cheatsheet》 https://www.smashingmagazine.com/2023/04/accessible-tap-target-sizes-rage-taps-clicks/ （2023-04-27，已核实）。

二、版式（Layout）

1. 结论：移动优先（mobile-first）仍是当前主流共识，"先做桌面版再用 max-width 往下改"被明确列为过时旧做法。 怎么做： css .card { display: block; } @media (min-width: 768px) { .card { display: grid; grid-template-columns: 1fr 1fr; } } 出处：MDN Glossary「Mobile First」（2025-07-18 更新） https://developer.mozilla.org/en-US/docs/Glossary/Mobile_First ；web.dev「Responsive web design basics」 https://web.dev/articles/responsive-web-design-basics （原文 2019，持续维护）。已核实。

2. 结论：断点应按内容的自然断裂点设计，而不是对应具体设备型号（如"iPhone Plus 宽度"）。 怎么做： css /* 反例：按设备型号 */ /* @media (max-width: 414px) { ... } 不推荐 */ /* 正例：按内容断裂点 */ @media (min-width: 46rem) { .layout { grid-template-columns: 1fr 2fr; } } 出处：MDN「Media query fundamentals」（2026-09-04 更新） https://developer.mozilla.org/en-US/docs/Learn_web_development/Core/CSS_layout/Media_queries ，原话："change the design at the size where the content starts to break"。已核实。

3. 结论：容器查询 @container（尺寸查询）已进入 Baseline "Widely available"（2025 年 8 月起），可放心用于组件级响应式，非常适合门店卡片/团餐套餐卡片这类可能出现在不同宽度栏位里的组件。 怎么做： css .store-card-wrap { container-type: inline-size; } @container (min-width: 320px) { .store-card { display: flex; } } 出处：容器查询 2023-02 进入 Baseline Newly available，2025-08 满 30 个月进入 Widely available（web.dev Baseline 系列）；caniuse.com/css-container-queries 实测全球支持率 94.87%（Chrome 106+/Firefox 110+/Safari 16+）。补充：2026-05 Chrome 148 让"仅按名称查询容器"和 style() 容器查询也进入 Baseline，这部分未完全核实，供参考。

4. 结论：clamp() 若最大/最小值写死为纯 px，vw 分量在浏览器缩放时不跟随，构成 WCAG 1.4.4（200% 缩放）违规；正确写法是上下限用 rem（随用户字号偏好缩放），中间过渡用 rem + vw 混合，且最大值不应超过最小值的 2.5 倍。 怎么做： css /* 正例 */ h1 { font-size: clamp(1.5rem, 1rem + 2.5vw, 3rem); } /* 反例：纯 px 上下限，缩放时可能失效 */ /* h1 { font-size: clamp(24px, 5vw, 48px); } */ 出处：Smashing Magazine《Addressing Accessibility Concerns With Using Fluid Type》 https://www.smashingmagazine.com/2023/11/addressing-accessibility-concerns-fluid-type/ （2023-11，已核实，含 "maximum font size must be less than or equal to 2.5 times the minimum" 原话）；Adrian Roselli《Responsive Type and Zoom》 http://adrianroselli.com/2019/12/responsive-type-and-zoom.html （2019-12，已核实）。2023 年 Smashing 一文可视为对 2019 年 Roselli 观点的复核确认。

5. 结论：安全区适配用 viewport-fit=cover + env(safe-area-inset-*)，并配合固定回退值，防止不支持的浏览器塌陷。 怎么做： html <meta name="viewport" content="initial-scale=1, viewport-fit=cover"> css .sticky-cta { padding-bottom: 12px; padding-bottom: max(12px, env(safe-area-inset-bottom)); } 出处：WebKit Blog《Designing Websites for iPhone X》 https://webkit.org/blog/7929/designing-websites-for-iphone-x/ （2017，已核实）；MDN env() https://developer.mozilla.org/en-US/docs/Web/CSS/env 。特性长期稳定，未见 2026 年重大变更。

6. 结论：100vh 在移动端因地址栏伸缩会溢出/跳动，应按场景选用 svh（小视口，保证任何时候不溢出，适合首屏动效容器）/ lvh（大视口，地址栏收起时的最大高度）/ dvh（动态视口，实时跟随地址栏，代价是滚动时可能有布局抖动）。 怎么做： css .hero-section { height: 100svh; } /* 七屏滚动首屏，优先保证不溢出 */ .fullscreen-video { height: 100dvh; } /* 需要跟手贴合视口 */ 出处：web.dev《The large, small, and dynamic viewport units》 https://web.dev/blog/viewport-units （2022-11-29，已核实）；caniuse.com/viewport-unit-variants 实测（2026 年数据）全球支持率 94.97%（Chrome 108+/Firefox 101+/Safari 15.4+），2023 年前的结论在 2026 年依然成立且支持面已广，多数场景无需再加 vh 回退。

7. 结论：软键盘弹出会顶飞布局，interactive-widget viewport meta 可控制这一行为，但目前只有 Chrome/Android 稳定支持，iOS Safari 截至 2026-09 仍未正式支持（WebKit 已在源码中实现但未发布）。 怎么做： html <meta name="viewport" content="width=device-width, initial-scale=1.0, interactive-widget=resizes-content"> 出处：Chrome for Developers https://developer.chrome.com/blog/viewport-resize-behavior （已核实，Chrome 108+ 支持，明确不影响 iOS 上的 WebKit）。2026 年最新复核：Bram.us《WebKit supports interactive-widget… and hopefully Safari will too?》 https://www.bram.us/2026/09/11/webkit-supports-interactive-widget-and-hopefully-safari-will-too/ （2026-09-11/12，已核实）确认 WebKit 已实现但尚未在 Safari/STP 正式版发布——iOS Safari 上做表单页仍需 visualViewport 做 JS 兜底。

8. 结论：横屏（landscape）主要坑点是视口变矮变宽，固定头部/悬浮 CTA 会吃掉大半屏幕；应在矮视口降级固定头部为非固定定位，并用 orientation 媒体特性调整版式；注意软键盘弹出也会让竖屏视口变宽、误触发 landscape 样式。 怎么做： css .site-header { position: fixed; } @media (max-height: 500px) { .site-header { position: static; } } @media (orientation: landscape) { .hero-blocks { flex-direction: row; } } 出处：Ahmad Shadeed《Responsive Height Design》 https://ishadeed.com/article/responsive-design-height/ （2020-10-20，已核实）；MDN orientation 媒体特性（2026-04-20 更新） https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/At-rules/@media/orientation （已核实，特别提醒软键盘弹出会误触发该特性）。

三、导航（Navigation）

1. 结论：隐藏导航（汉堡菜单）会使内容可发现性显著下降——具体幅度是"超过 20%"，不是坊间常说的"腰斩/减半"。原文："This measure showed a more than 20% drop in discoverability on sites with hidden navigation, compared with sites with visible or combo navigation." 怎么做：六个页签不要全塞进汉堡菜单；最常被访问的 1~2 个核心入口应保持常驻可见。 出处：NN/g《Hamburger Menus and Hidden Navigation Hurt UX Metrics》，2016-06-26，https://www.nngroup.com/articles/hamburger-menus/ （已核实原文逐字引用）。

2. 结论：隐藏导航还会拖慢任务耗时、提高感知难度，且桌面端受损比移动端更严重：桌面端"至少慢 39%"，移动端"慢 15%"；难度评分隐藏导航比可见导航高 21%，比组合导航高 11%（179 名参与者、6 个网站，含手机和桌面，与 WhatUsersDo 合作完成）。 怎么做：六个页签中若有高频功能（如"联系我们"），应做成常驻标签，不折进汉堡菜单。 出处：同上 NN/g 2016，https://www.nngroup.com/articles/hamburger-menus/ 及方法论说明 https://www.nngroup.com/articles/hidden-navigation-methodology/ （已核实）。

3. 结论：2025 年 NN/g 复核确认——汉堡图标本身的可识别性已提升（用户普遍认得），但"隐藏内容导致互动减少、任务成功率下降"的核心问题并未被推翻，只是新研究未重新测耗时/成功率数据。原文："These fundamental design guidelines have not changed"，同时坦承新研究"can't confirm whether task time or success rates have changed over the years"。 怎么做：不能以"用户现在都认识汉堡图标"为理由把六个页签整体收进汉堡菜单，2016 年的可用性代价结论仍应视为成立。 出处：NN/g《The Hamburger-Menu Icon Today: Is it Recognizable?》，2025-06-13，https://www.nngroup.com/articles/hamburger-menu-icon-recognizability/ （已核实，属 2023 年后复核）。

4. 结论：针对"6 个页签+部分带下拉"的营销官网，NN/g 数据支持用"组合导航"（几个高频入口常驻+汉堡收纳其余），而非全收进汉堡：桌面端可见/组合导航使用率 48%/50%，隐藏导航仅 27%；移动端组合导航使用率 86%，是纯隐藏导航（57%）的 1.5 倍；且 NN/g 建议导航选项 ≤5 个时可全部常驻，超过 5 个（本案例正好是 6 个）才需要考虑折叠。 怎么做：把 2~3 个高转化页签做成常驻横向标签，其余收进汉堡菜单。 出处：NN/g《Hamburger Menus and Hidden Navigation Hurt UX Metrics》2016 + 《Basic Patterns for Mobile Navigation》，2015-11-15，https://www.nngroup.com/articles/mobile-navigation-patterns/ （已核实；2015 年发布，未找到直接推翻该阈值建议的 2023 年后复核，但 2025 年图标可识别性研究等近期文章仍在引用）。

5. 结论：子菜单在手机上有两种主流展开模式——手风琴（accordion）占用空间最小、适合层级浅且想让用户留在原页面的场景；全屏分层下钻（drill-down）适合层级深、分类多的场景，但会让用户离开当前上下文。唯有 caret（尖角）图标能有效提示"可展开"。 怎么做：带下拉的页签优先用手风琴展开，仅当某页签下有较多三级分类时才用 drill-down。 ```html 产品 ▾
   

``` 出处：NN/g《Mobile Subnavigation》、《Accordion Icons: Which Signifiers Work Best?》，https://www.nngroup.com/articles/mobile-subnavigation/ 、https://www.nngroup.com/articles/accordion-icons/ （已核实）。

1. 结论：Disclosure（展开/收起）模式的正确 ARIA 写法——控制元素必须是 <button>，用 aria-expanded 标示状态，aria-controls 指向被控内容区，展开时 JS 同步更新 aria-expanded 并移除 hidden，键盘 Space/Enter 均应可触发。 怎么做：见上方代码示例。 出处：W3C WAI-ARIA Authoring Practices Guide，Disclosure Pattern，https://www.w3.org/WAI/ARIA/apg/patterns/disclosure/index.html （已核实，官方规范持续维护）。

2. 结论：移动端子菜单绝不能依赖 :hover 触发（触屏设备无法悬停），必须改为 tap/click，并用 hover 媒体特性做能力检测而非按视口宽度判断，避免可 hover 的触屏平板被误判。 怎么做： css @media (hover: hover) and (pointer: fine) { .has-submenu:hover .dropdown { display: block; } } 不支持 hover 的设备完全交给 JS click/tap 事件处理展开逻辑。 出处：MDN hover CSS 媒体特性，https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/At-rules/@media/hover （已核实）；Smashing Magazine《A Guide To Hover And Pointer Media Queries》，2022-03（标题日期已核实，正文未逐字核对，视为部分核实）。

3. 结论：粘顶导航长期占屏是真实代价，移动端弹出软键盘时页面可用高度进一步被压缩（需要输入的表单场景应考虑放弃 sticky 改用手风琴）；"滚动隐藏（hide-on-scroll）"是缓解方案——下滑隐藏、上滑立即重新出现，过渡建议 300~400ms，仅当页面内容超过 3 屏时才值得引入。 怎么做： css .header { position: sticky; top: 0; transition: transform 300ms ease; } .header--hidden { transform: translateY(-100%); } 出处：Smashing Magazine《Designing Sticky Menus: UX Guidelines》，2023-05-12，https://www.smashingmagazine.com/2023/05/sticky-menus-ux-guidelines/ （已核实，引用 NN/g 研究员 Page Laubheimer 的建议）。

4. 结论：GOV.UK Design System 建议先做"信息架构简化"再考虑加导航——只有当服务被同一用户反复访问、涉及多任务、且任务顺序不固定时才需要顶部导航链接。 怎么做：对六个页签+下拉的官网，先审视是否真的需要 6 个一级入口，而不是先纠结交互形式（手风琴 vs drill-down）。 出处：GOV.UK Design System《Help users to navigate a service》，https://design-system.service.gov.uk/patterns/navigate-a-service/ （已核实；页面未单独标注发布日期，文中提及配套 Service Navigation 组件于 2024-08 引入，内容视为 2024 年后维持更新）。

四、表单（Forms）

1. 结论：姓名、邮箱、电话、城市、邮编字段有明确的 autocomplete 标准取值，浏览器据此提供自动填充和对应软键盘布局；中国场景常省略邮编，但国际标准仍建议保留该字段供跨境/异地用户使用。 怎么做： html <input type="text" name="fullname" autocomplete="name"> <input type="email" inputmode="email" autocomplete="email"> <input type="tel" inputmode="tel" autocomplete="tel" enterkeyhint="next"> <input type="text" autocomplete="address-level2"> <!-- 城市 --> <input type="text" inputmode="numeric" autocomplete="postal-code"> 出处：MDN《autocomplete HTML attribute》，https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/autocomplete （页面 2026-08-27 修改，当前有效，已核实）。

2. 结论：预订日期字段，近期日期优先用浏览器原生 <input type="date">；生日等"记忆型"日期，GOV.UK 因用户测试中滚动选年费力，改用拆分的日/月/年三个文本框，NN/g 也认为直接打字比滚动选择器更高效。 怎么做： ```html

日 ``` 出处：GOV.UK Design System「Dates pattern」，https://design-system.service.gov.uk/patterns/dates/ （已核实，持续维护页面）；NN/g《Date-Input Form Fields》，2017-01-22，https://www.nngroup.com/articles/date-input/ （已核实，未找到 2023 年后的复核，视为可能过时——现代浏览器原生 date picker 体验已比 2017 年明显改善，落地时可优先信任原生控件）。

1. 结论：人数（用餐/订场）这类"看起来是数字但不是数量运算"的字段，应避免 type="number"（会带来意外的加减箭头/滚轮改值风险），改用 inputmode="numeric" + pattern。这是 GOV.UK 团队 2020 年做出的明确决策，MDN 2026 年的页面仍在引用。 怎么做： html <input type="text" inputmode="numeric" pattern="[0-9]*" autocomplete="off"> 出处：MDN《<input type="number"> – Accessibility concerns》（2026-09-10 修改） https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/number ；GOV.UK 原始决策 https://technology.blog.gov.uk/2020/02/24/why-the-gov-uk-design-system-team-changed-the-input-type-for-numbers/ （2020，已核实，2026 年仍被引用，视为仍成立）。

2. 结论：enterkeyhint 控制软键盘回车键的文案/图标，应按该字段是否是表单最后一个字段选择 next 或 done（表单外可用 search/go/send）。 怎么做：<input enterkeyhint="next">（中间字段）、<input enterkeyhint="done">（末尾字段） 出处：MDN《enterkeyhint global attribute》（2026-04-17 修改），https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/enterkeyhint （已核实）。

3. 结论：iOS Safari 中 <input>/<select> 字号小于 16px，聚焦时会自动放大页面（经典 bug），解决办法是把表单控件字号设为 16px 及以上，而不是用 user-scalable=no 破坏无障碍缩放。 怎么做：input, select, textarea { font-size: 16px; } 出处：CSS-Tricks《16px or Larger Text Prevents iOS Form Zoom》，2021-05-04，https://css-tricks.com/16px-or-larger-text-prevents-ios-form-zoom/ （已核实；经检索确认该行为在 2024-2026 期间未变化，Apple 未调整此机制，视为仍成立）。

4. 结论：行内校验（inline validation）出现时机上，Baymard 和 GOV.UK 结论有细微差异，需分开引用——Baymard 建议在字段失焦（blur）时校验，反对用户还没打完字就报错；GOV.UK 更保守，默认只在用户点击"继续/提交"时才校验，除非有用户研究证明实时校验确有益处。Baymard 研究还发现 31% 的网站完全没有行内校验。 怎么做： js field.addEventListener('blur', validate); field.addEventListener('input', () => { if (wasInvalid) validate(); }); // 改正后立即清除错误 出处：Baymard《Usability Testing of Inline Form Validation》，2024-01-09，https://baymard.com/blog/inline-form-validation （已核实）；GOV.UK Design System「Validation pattern」，https://design-system.service.gov.uk/patterns/validation/ （已核实，原文："Do not validate when the user moves away from a field... Wait until they try to move to the next part of the service"）。

5. 结论：表单应使用单列布局，避免多列并排字段——Baymard 发现多列表单会让用户误判填写顺序/必填项，增加出错和漏填概率（16% 的电商网站仍在用多列布局）；只有语义上天然成组的字段（如姓+名）可同行并排。 怎么做： css .form { display: flex; flex-direction: column; gap: 16px; } 出处：Baymard《Avoid Extensive Multicolumn Layouts》，2023-10-31，https://baymard.com/blog/avoid-multi-column-forms （已核实）。

6. 结论：分步表单（multi-step）在用户对流程不熟悉、字段多、需要分组降低认知负荷时有效；但用户重复执行的操作、需跨步骤对比信息、或专家用户追求效率的场景，分步反而增加点击成本、降低转化。留资表单字段少时，是否分步取决于字段能否自然分组，而非单纯字段多就拆。 怎么做：字段能分成 2 组以内、用户是一次性/低频填写时可分两步（如"姓名+电话"一步，"日期+人数+城市"一步）；否则用单页滚动。 出处：NN/g《Wizards: Definition and Design Recommendations》，首发 2017-06-25，2024-01-24 复核更新，https://www.nngroup.com/articles/wizards/ （已核实，属 2023 年后复核）。

7. 结论：粘底提交按钮在移动端软键盘弹出时容易被遮挡或跳动，visualViewport API 可监听可见视口尺寸变化重新定位按钮，interactive-widget viewport meta 是更新的声明式方案（但 iOS Safari 截至 2026-09 尚未支持，见版式话题第 7 条），两者可配合做兜底。 怎么做： html <meta name="viewport" content="width=device-width, initial-scale=1, interactive-widget=resizes-content"> js window.visualViewport.addEventListener('resize', () => { submitBtn.style.bottom = (window.innerHeight - window.visualViewport.height) + 'px'; }); 出处：MDN《VisualViewport API》（2026-08-12 修改），https://developer.mozilla.org/en-US/docs/Web/API/VisualViewport ；Chrome for Developers https://developer.chrome.com/blog/viewport-resize-behavior （2022-10-28，已核实；2023 年前发布，但 2026-09-11 的 Bram.us 文章证实该特性仍在持续演进被跟进）。

8. 结论：label 必须始终可见，不能用 placeholder 代替 label——placeholder 消失后用户会忘记该填什么，尤其对认知/视觉障碍用户不友好。NN/g 首发于 2014 年，2018 年修订，2024 年再次复核确认结论不变。 怎么做： html <label for="phone">手机号</label> <input id="phone" type="tel" inputmode="tel" autocomplete="tel" placeholder="例如 138 0000 0000"> placeholder 只做格式示例，不承担说明字段用途的功能。 出处：NN/g《Placeholders in Form Fields Are Harmful》，首发 2014-05-11，2018-09-10 修订，2024-01-26 复核确认，https://www.nngroup.com/articles/form-design-placeholders/ （已核实，属 2023 年后复核）。

手机网页界面优化调研（2026-09-21）

场景：静态营销+留资官网，首页七屏 JS 驱动 --p 滚动动效（非原生 animation-timeline），首屏 LCP 是 13MB 自动播放 hero 视频（poster 163KB），全站 svh 打头 vh 兜底，有 PostHog 会话回放 + web_vitals RUM，测试用 Playwright。

标注说明：「未核实」= 我没能直接打开原文核实，只有搜索摘要/二手转述，请自行复核再采信。没有标「未核实」的都至少打开过一次原文或经多个独立信源交叉印证。

话题5：速度即界面（LCP / INP / CLS / 图片 / 字体 / JS / 弱网测试）

1. 结论：INP 已在 2024-03-12 正式取代 FID 成为 Core Web Vital，门槛为「好 ≤200ms / 待改进 200–500ms / 差 >500ms」；LCP 门槛 ≤2.5s（差 >4s），CLS ≤0.1（差 >0.25），这三个数字截至 2025-05-07（web.dev 该文最近一次更新）仍未变。 怎么做：把这三个数字直接写进你们的 RUM 告警阈值，不要用「2026 新门槛」之类的二手说法覆盖它们。 出处：Interaction to Next Paint becomes a Core Web Vital on March 12（2024）；How the Core Web Vitals metrics thresholds were defined（2020 发布，2025-05-07 更新，已核实原文）

2. 结论：网上大量「2026 Core Web Vitals 门槛有重大调整/新增指标」的说法（多来自 SEO 营销站）目前查不到 Google/web.dev 官方一手确认；官方文档截至 2025-05 更新仍是三项老门槛。TTFB、FCP 只是诊断参考指标，从未是 Core Web Vital，不会直接进入排名判定。 怎么做：不要因为这类文章去改动你们的告警阈值或汇报口径，继续以 LCP/INP/CLS 三项为准；TTFB/FCP 可以作为内部诊断的前置信号但不要当 CWV 汇报。 出处：多篇 2026 SEO 站点（rivuletiq.com、webvitals.tools 等）的说法【未核实，且与官方一手文档冲突，倾向不采信】

3. 结论：视频元素现在可以作为 LCP 候选——浏览器会用 poster 图或视频首帧参与 LCP 计算（此前无 poster 的 video 不算 LCP 候选，后来修复）。 怎么做：hero 视频必须给 poster，且 poster 要参与 LCP 优化，而不是只优化「文字」或「视频本身」。 出处：Video performance | web.dev（未核实原文，来自搜索摘要）

4. 结论：给 poster 图加 <link rel="preload" as="image" fetchpriority="high"> 能显著提前 LCP（Google 内部案例把 LCP 从 2.6s 压到 1.9s），但如果视频不是视口内最大元素，抢先加载 poster 反而会跟其他关键资源抢带宽，拖慢真正的 LCP 元素。 怎么做：先用 Chrome DevTools 或 PostHog web_vitals 数据确认「谁是当前 LCP 元素」，再决定要不要给 poster 加 fetchpriority=high；同时给 <video> 本身设 preload="none" 或 preload="metadata"，避免浏览器默认预抓视频数据抢占带宽。 出处：Optimize resource loading with the Fetch Priority API；Tip: fetchpriority=high；How To Optimize LCP For Video Elements | DebugBear（均未核实原文，来自搜索摘要，但三个独立信源结论一致，可信度较高）

5. 结论：13MB 自动播放 hero 视频在手机上是「结构性反模式」——<video autoplay> 会让浏览器提前抢下载视频数据，直接跟首屏 CSS、字体、hero 图片抢带宽，被多篇文章称为「视觉丰富网站 LCP 失败的头号原因」。 怎么做：手机端（尤其 Save-Data / 慢网络 / 移动信号）应该直接不给视频，只给静态图；用 navigator.connection.saveData 或 Network Information API 判断，配合媒体查询按屏宽二次确认。 出处：Delivering Fast and Light Applications with Save-Data | web.dev（未核实原文）；DebugBear/Mintec 博客对 hero video 反模式的讨论【未核实】

6. 结论：loading="lazy" 绝对不能用在首屏/视口内图片（包括 LCP 图片）——WordPress 曾因为把视口内图片也 lazy-load 导致 LCP 回归，改成「只 lazy-load 视口外图片」后 LCP 不但恢复还略有提升。 怎么做：首屏七屏动效里，只有第一屏的图/poster 不能加 loading="lazy"，且应加 fetchpriority="high"；第二屏及以后（滚动进入前）的图统一 loading="lazy"。 出处：The performance effects of too much lazy loading | web.dev（未核实原文，来自搜索摘要）；Browser-level image lazy loading | web.dev

7. 结论：给图片/视频设置 width/height 属性或 CSS aspect-ratio，浏览器会在资源下载完成前就用这两个值算出宽高比、提前预留版面空间，从而避免 CLS；占位符/骨架屏撤下时同样要小心不能瞬间塌陷空间，否则会产生同等大小的位移。 怎么做：七屏滚动动效里凡是靠 JS 改 --p 驱动位移/缩放的容器，本身也要有固定的 width/height 或 aspect-ratio 兜底，不能等 JS 首次执行才定形。 出处：Optimize Cumulative Layout Shift | web.dev（2025-02-07 更新，已核实原文）

8. 结论：字体应 font-display: swap（保证文字先用后备字体可见，字体到位后再替换），crossorigin 属性对自托管字体也必须加（字体算 CORS 资源），子集化 WOFF2 可再省 80%+ 体积；size-adjust 可以让后备字体和目标字体的度量接近，减少字体替换时的布局抖动。 怎么做：别对每个字重都 <link rel=preload>——会跟 hero 图/poster 抢带宽拖慢首绘；只 preload 首屏真正用到的 1-2 个字重的子集文件。 出处：Best practices for fonts | web.dev；Optimize WebFont loading and rendering | web.dev（均未核实原文，来自搜索摘要）

9. 结论：主线程被长任务占用是 INP 差的主因；scheduler.yield() 是 2024-09（Chrome 129）上线的新 API，专门用来把长任务切段让出主线程；但截至目前 Safari 不支持 scheduler.yield()（Edge 129、Firefox 142 支持），iOS 上必须用 setTimeout 兜底。 怎么做：七屏滚动动效的 JS 里如果有大段计算（算 --p、做插值），要用 scheduler.yield()（配 polyfill 兜底 setTimeout(0)）切成小块，不能假设 iOS Safari 也有原生支持。 出处：Use scheduler.yield() to break up long tasks | Chrome for Developers（未核实原文，但"Chrome 129 / Safari 不支持"这一关键点被多个独立信源印证，可信度高）

10. 结论：Chrome DevTools 固定倍数的 CPU 节流（4x/6x/20x）长期被诟病不够准——高端 M 系芯片开 20x 节流可能都还比真实低端手机快；Chrome 134 起新增「CPU throttling calibration」，会现场标定出你这台机器对应「低端机」「中端机」各自该用多少倍节流（例如低端机 14.7x、中端机 3.6x），比固定倍数更接近真实体验。 怎么做：不要只依赖固定 4x/6x 跑 Lighthouse；用校准后的节流跑一遍七屏动效，再结合 PostHog web_vitals 的真实 CrUX/RUM 数据核对，两者出现明显偏差（lab 绿、field 红）时以 field 数据为准做决策。 出处：More accurate DevTools performance debugging using real-world data | Chrome for Developers；Why lab and field data can be different | web.dev（均未核实原文，来自搜索摘要，多信源印证）

11.（补充，未核实）结论：Harry Roberts（csswizardry）2025-08 的文章建议用真实的低/中端安卓机做性能基准（例如三星 Galaxy A15 5G 作低端、Galaxy A54 5G 作中端），认为固定倍数节流不足以代表真实碎片化设备。 怎么做：如果条件允许，采购一台这类中低端安卓机做真机回归测试，而不是只依赖 Chrome DevTools 节流。 出处：Low- and Mid-Tier Mobile for the Real World (2025) – CSS Wizardry【我没能直接打开原文（域名被环境拦截），仅来自搜索引擎摘要，请务必自行核实设备型号和结论细节】

话题6：动效（该砍什么 / 只动 transform-opacity / reduced-motion / 滚动驱动动画的坑 / 自动播放兜底）

1. 结论：动画应严格限制在 transform 和 opacity 这两个属性上——它们可以完全在合成线程（compositor thread）上跑，跳过布局（layout）和绘制（paint），即使主线程被长任务占满也能维持 60fps；其他属性（如改 width/top/filter 等）会触发布局或重绘，需要主线程参与。 怎么做：七屏动效里凡是用 JS 写 --p 去驱动的位移/缩放/透明度变化，落到 CSS 上最终必须是 transform/opacity，不要用 --p 去间接改 top/left/width 之类会触发重排的属性。 出处：Stick to Compositor-Only Properties and Manage Layer Count | web.dev；Animations and performance | web.dev（均未核实原文，来自搜索摘要，与业界公认常识一致）

2. 结论：backdrop-filter/blur 的 GPU 合成开销跟「模糊半径 × 元素像素面积」成正比——一张 300×200px 卡片上 12px 模糊代价很小，但全视口 40px 模糊在高分辨率屏上是百万级像素的实时采样，代价很大；动画化 blur 半径本身（比如让模糊值随 --p 变化）会每帧重新触发合成，是最贵的做法之一。 怎么做：如果七屏里有毛玻璃效果，不要让 blur 半径本身参与动画；改成「预先算好模糊结果的图层 + opacity 淡入淡出」，模糊只算一次。同一屏内同时叠加的大面积 backdrop-filter 元素别超过 3-4 个。 出处：多篇性能博客交叉印证（F22 Labs、Empire UI 等）【未核实，非一线权威信源，建议自行用 Chrome Performance 面板实测你们具体七屏的合成耗时来验证这个经验值】

3. 结论：prefers-reduced-motion: reduce 的正确做法是「减少」而不是「全部关掉」——纯粹把所有动画砍成 0 反而会让部分认知障碍/注意力障碍用户失去有帮助的视觉线索；官方建议是把位移类效果（缩放、旋转、平移波浪）换成不产生「运动感」的效果（淡入淡出、颜色渐变）。 怎么做：给七屏滚动动效写两套：普通用户走当前的位移/缩放效果，prefers-reduced-motion: reduce 命中时把同样的时间轴改成纯 opacity 渐变，而不是直接把 JS 监听整个禁用掉。 出处：prefers-reduced-motion: Sometimes less movement is more | web.dev（未核实原文，来自搜索摘要）

4. 结论：原生 CSS 滚动驱动动画（animation-timeline: scroll() / view()）目前浏览器支持现状——Chrome/Edge 115+（2023-07 起无需 flag）；Safari 是在 Safari 26（2025-09 随 iOS 26/macOS Tahoe 发布）才正式支持，到今天（2026-09-21）已经上线约一年，属于「现在可用」而非「还在实验」；Firefox 132+ 仍在 flag 后面，还未进入稳定版（截至该搜索结果的时间点）。 怎么做：既然你们目前是 JS 写 --p 而不是原生 animation-timeline，现在（Safari 26 已铺开近一年）是评估迁移到原生 CSS 方案的合适窗口——原生方案能让动画运行在合成线程/独立于主线程，天然规避掉 JS scroll 监听在 iOS 上的抖动问题；但仍要留 JS 兜底给 Firefox（未稳定支持）。 出处：A guide to Scroll-driven Animations with just CSS | WebKit（已核实原文，Safari 26 beta 于 2025-06-20 发布该文时状态）；Release Notes for Safari Technology Preview 238 | WebKit（未核实原文，标注 2026-02 起加入线程化时间动画同步）；Firefox 状态来自搜索摘要【未核实】

5. 结论：JS 监听 scroll 事件驱动动画的老路子（也就是你们现在写 --p 的方式）跑在主线程，一旦回调里有实际计算就会比手指落后一两帧，产生"跟手感差"；iOS 上还有额外坑——Safari 地址栏收缩/展开会持续触发 resize/viewport 变化事件，"像连珠炮一样"打断/重启 touchmove 序列，导致滑块类交互在 iOS 15 之后变得"抽风"。 怎么做：如果暂时不能迁移到原生 animation-timeline，至少要给 scroll 监听加 { passive: true }，并把实际计算放到 requestAnimationFrame 回调里而不是直接在 scroll 回调里算，同时监听 visualViewport 的 resize 而不是 window 的 resize 来处理地址栏收缩造成的高度跳变。 出处：Understanding Phantom window.resize Events in iOS | John Kavanagh【未核实，来自搜索摘要】；iOS Safari 动态工具栏机制的多篇技术博客交叉印证【未核实】

6. 结论：will-change 滥用会导致浏览器为每个声明的元素单独开一个合成层（compositor layer），层数一多会吃掉大量 GPU 显存，在中低端手机上反而更卡、更耗电——这是业界公认的常见反模式，但本次搜索没能找到 Harry Roberts/csswizardry 本人专门写过这个主题的一手文章。 怎么做：will-change 只加在「即将开始动画」的元素上，动画结束后用 JS 移除该声明（比如动画 transitionend/animationend 后清掉），不要写死在 CSS 里长期挂着；七屏如果同时有多个大图层都挂 will-change: transform，先用 Chrome DevTools 的 Layers 面板数一下当前有多少层。 出处：未找到可核实的一手信源，此条结论基于浏览器渲染原理的公开共识【未核实，建议用 Layers 面板自行验证你们的具体页面】

7. 结论：iOS 低电量模式（Low Power Mode）下 Safari 会直接禁用视频自动播放（即使是 muted+inline+autoplay），CSS 层面无法覆盖这个行为；正确兜底是检测 video.play() 返回的 Promise 是否被拒绝（reject），拒绝后无缝切换到一张动图（GIF/WebP/APNG）或干脆一张静态图 + 明显的「点击播放」按钮。 怎么做：hero 视频的自动播放调用要用 video.play().catch(() => { /* 切静态 poster 或加播放按钮 */ }) 包一层，不要假设 autoplay 属性一定生效。 出处：多篇技术博客与 Apple Developer Forums 帖子交叉印证（如 Safari Low Power Mode Video Playback Issue）【均未核实原文，但结论在多个独立信源里一致，可信度较高；Apple 官方文档没有直接确认这一行为细节，建议真机在低电量模式下实测】

8. 结论：Nielsen Norman Group 对 parallax 效果的可用性研究发现，大多数用户滚动很快、扫读关键词，根本不等 parallax 动画播完，导致设计者以为"用户会看到"的内容其实被错过；在移动端，scroll hijacking（劫持原生滚动手势）尤其容易激怒用户，也会破坏读屏器/键盘用户对滚动状态的预期。 怎么做：七屏动效的节奏不能比用户实际滑动速度慢——用户可以比设计预期更快地划过一屏，动画必须能跟手（或者至少不能挡住内容可读性）；任何情况下都不要拦截原生 touch 滚动去做"一屏一屏吸附"的强制翻页。 出处：What Parallax Lacks - NN/G；Scrolljacking 101 - NN/G（均未核实原文，来自搜索摘要，但 NN/G 是一线权威信源）

话题7：怎么测（真机 vs 模拟器 vs 设备模式 / Playwright / 触控与横向溢出 / 视觉回归 / 真机云 / PostHog 会话回放）

1. 结论：Chrome DevTools 设备模式的渲染引擎始终是桌面 Blink，不是 Safari/WebKit——意味着 iOS 特有的 bug（比如 iOS 地址栏收缩、惯性滚动的橡皮筋效果、Safari 特有的 CSS 渲染差异）根本不会在设备模式里复现；同时它也不模拟真实 CPU 架构、GPU 驱动、内存压力、触摸数字化器，只是"外形像手机"的桌面浏览器。 怎么做：设备模式只用来快速看布局断点是否正确，不能用它来判断"这个动效在 iPhone 上流不流畅"或"这个 iOS Safari bug 是否存在"——这两类问题必须上真机或真机云。 出处：多篇技术博客交叉印证（Chrome DevTools Device Mode: 7 Limitations to Know、Chrome 官方 Simulate mobile devices with device mode 文档存在但未直接核实其原文措辞）【未核实原文，来自搜索摘要，多信源一致】

2. 结论：Playwright 的 webkit 引擎虽然和 Safari 同源（都基于 WebKit），但并不等于真实 iOS Mobile Safari——它是桌面 WebKit 加了 UA/viewport 伪装，覆盖不了 Mobile Safari 独有的滚动行为、fixed 定位怪癖、视口处理；官方限制下 Playwright 也无法直接连真机上的 Mobile Safari 跑自动化。据估计 Playwright WebKit 能捕捉到约 80-90% 的 WebKit 相关渲染/JS bug，但版本/内存压力/OS 策略相关的问题只有真机才能复现。 怎么做：Playwright webkit 项目适合日常回归（逻辑、可访问性树、大部分布局），但涉及 iOS 地址栏收缩导致的 svh/dvh 高度跳变、惯性滚动手感这类问题，必须补一层真机（云真机或本机 Simulator/真 iPhone）验证，不能只信 Playwright 跑绿。 出处：多篇测试类博客交叉印证（BrowserStack、TestMu AI、Firm86 等）【未核实原文，来自搜索摘要】

3. 结论：Playwright 的设备描述符（如 devices['iPhone 15']）一次性设置五个核心字段：viewport（CSS 像素布局尺寸）、userAgent、deviceScaleFactor（对应 window.devicePixelRatio）、isMobile（决定是否启用移动端 viewport meta 行为和事件模型，这个字段只在 Chromium 上真正生效）、hasTouch（是否暴露 Touch API、page.tap() 能否用）。 怎么做：写 Playwright config 时，用 { ...devices['iPhone 14'] } 展开这五个字段，而不是自己手写 viewport 尺寸——否则很容易漏掉 isMobile/hasTouch，导致触摸相关的 bug（比如 hover 态卡住不消失）测不出来。 出处：多篇 Playwright 测试指南交叉印证（qaskills.sh、hyperping.com 等）【未核实原文，来自搜索摘要，与 Playwright 公开行为一致，可信度较高】

4. 结论：横向溢出可以用 Playwright + page.evaluate() 自动断言：document.documentElement.scrollWidth > document.documentElement.clientWidth 为真即代表页面存在横向溢出；也可以遍历所有元素找出具体是谁溢出的。触控目标尺寸可以用 element.boundingBox() 拿到真实渲染后的宽高，断言是否 ≥ WCAG 2.2 AA 的 24×24px（2.5.8 Target Size 最低要求）或更严格的 44×44px（AAA / 常见设计规范）。 怎么做：在 Playwright 里对七屏的关键容器写一条通用断言——遍历所有 <a>/<button>/可点击元素，boundingBox() 宽高任一小于 24px 就 fail；再单独写一条 scrollWidth <= clientWidth（含少量误差容忍）的断言，跑在 devices['iPhone SE'] 这种小屏设备上（小屏最容易暴露横向溢出）。 出处：多篇 QA 类博客交叉印证【未核实原文，来自搜索摘要】；WCAG 2.5.8 数值已通过 W3C 官方 WCAG 2.2 规范核实（见话题8）

5. 结论：Playwright 内置 toHaveScreenshot() / toMatchSnapshot() 做视觉回归，可以针对设备描述符（而不是随便自定义 viewport 尺寸）分别截图对比，因为 Safari 和 Chrome 处理安全区（safe area）、缩放、取整的方式不同，用真实设备描述符截图更接近生产环境的呈现；阈值可以用 maxDiffPixels 或 maxDiffPixelRatio 控制敏感度。 怎么做：至少给 devices['iPhone 14']（常规 iOS）、devices['iPhone SE']（小屏，最容易暴露 svh/vh 兜底问题）、devices['Pixel 7']（Android 对照组）各留一套视觉回归基线，专门盯七屏动效在 --p 走到 0%/50%/100% 时的关键帧截图。 出处：多篇 Playwright 视觉测试指南交叉印证（bug0.com、testdino.com 等）【未核实原文，来自搜索摘要】

6. 结论：真机云（BrowserStack、LambdaTest 等）能补上模拟器/Playwright WebKit 覆盖不到的部分——BrowserStack 号称 3500+ 真实物理设备，LambdaTest 在 2025-07 宣布支持在真实 iOS 设备上跑 Playwright（通过远程 WebSocket/CDP 连接），可以接入 CI/CD。 怎么做：日常 PR 用本地 Playwright（webkit + chromium 项目）跑得快；上线前的关键路径（首屏 LCP、七屏动效流畅度、留资表单提交）建议每次发版前在真机云上手动或自动跑一轮 smoke test，尤其是低端 Android 机型。 出处：LambdaTest Enables Playwright Testing on iOS Real Devices（2025-07，未核实原文，来自搜索摘要）

7. 结论：PostHog 的 Heatmap/会话回放能标出 rage click（同一元素快速点击 ≥5 次，代表交互没反应符合用户预期）和 dead click（点了交互元素但几秒内页面没任何反应，常见于「看起来能点但其实是 disabled 的按钮」或「事件绑晚了」），可以按自定义事件、用户属性、feature flag 筛选后存成 playlist 分享给团队；但目前按「设备类型（移动端/桌面端）」筛选还不算很顺手，官方 GitHub 上有相关 feature request（需要靠事件属性里的 OS/Device Model 间接筛）。 怎么做：用你们已经接的 PostHog，专门建一个「移动端 rage click + dead click」的 saved filter/playlist（先按 $device_type 或类似属性筛出移动端会话，再叠加 rage/dead click 条件），每周过一遍，定位七屏动效里"看起来能点/滑但其实卡住"的地方。 出处：Heatmaps - Docs - PostHog；Session replay: Add Platform and Device Model as replay properties · Issue #26669（均未核实原文，来自搜索摘要，但 GitHub issue 标题本身就是一手证据，指向"按设备类型筛选目前不够顺手"这个结论）

话题8：手机相关可访问性

1. 结论：现代 iOS Safari 会直接忽略 user-scalable=no 和 maximum-scale=1，用户仍然可以双指缩放——也就是说这两个设置现在既不该写（因为违反 WCAG 1.4.4 Resize Text / 1.4.10 Reflow），写了在 iOS 上也不再生效，纯粹是"防君子不防小人"的历史遗留代码。 怎么做：viewport meta 标签直接写 width=device-width, initial-scale=1 就够了，删掉 user-scalable=no/maximum-scale；表单输入框字体设 font-size: 16px（1rem）以上，这样 iOS 就不会因为"输入框字号太小"而在聚焦时强制放大整个页面（这是大多数人当初加 maximum-scale=1 真正想解决的问题，用字号就能正确解决）。 出处：多篇技术博客交叉印证（含 lukeplant.me.uk 的专门文章，但该域名本次环境拦截未能直接打开核实）【未核实原文，来自搜索摘要，多信源结论一致，可信度较高；核心结论「iOS 现在会忽略这两个 viewport 设置」建议你们自己在真机上验证一次】

2. 结论：WCAG 1.4.4（Resize Text，AA）要求文字能放大到 200% 且不丢失内容/功能；1.4.10（Reflow，AA）要求在 320px CSS 像素宽度（对应常见手机横向缩放 400% 后的等效宽度）下内容能重排、不需要横向滚动（除了地图、表格这类本质上需要横向滚动的内容例外）。 怎么做：拿 Chrome DevTools 把视口宽度设成 320px（不是设备宽度，是真正 320px），检查七屏内容是否重排正常、有没有横向溢出——这和话题7里 Playwright 的 scrollWidth 断言应该对应同一条验收标准。 出处：W3C WCAG 2.2 规范原文（已核实规范列表，1.4.4/1.4.10 属于 WCAG 2.1 引入、2.2 延续的既有条款）

3. 结论：WCAG 1.4.3（AA）4.5:1 对比度只是「下限」，且在深色模式/近黑色场景下这个比值公式本身会给出不可靠的判断（同样 4.5:1 的对比度，实际可读性可能天差地别）；业界更精细的 APCA（Accessible Perceptual Contrast Algorithm）曾被寄望写入 WCAG 3，但已在 2023 年初被从 WCAG 3 工作草案里移除（"exploratory" 内容，未获得工作组足够支持），截至 2026-04（Adrian Roselli 原文核实日期）WCAG 3 到底用什么对比算法仍「尚未确定」，WCAG 3 本身预计要到 2030 年之后才可能定稿。 怎么做：现阶段该用哪个标准做验收——继续以 WCAG 2.x 的 4.5:1（正文）/3:1（大字/粗体）为准，户外强光场景可以额外用 APCA 做「加餐」自查（更贴近真实可读性），但不要把 APCA 当成法定合规依据，也别信"WCAG 3 已经改用 APCA"这类说法。 出处：WCAG3 Contrast as of April 2026 — Adrian Roselli（已核实原文，2026-04-10 发布，2026-04-13 更新——是本次调研里少数直接命中"2026 年状态"的一手信源）

4. 结论：VoiceOver（iOS）核心手势——单指左右滑动在元素间移动、双击激活当前元素、双指下滑朗读全文；TalkBack（Android）核心手势——单指右滑按阅读顺序移动到下一项、左滑回上一项，双指起的手势用来替代系统手势（比如原本单指上滑解锁，TalkBack 开启后改双指上滑）。 怎么做：七屏动效的每一屏在读屏模式下应该能被顺序线性读完（滑动手势触发的应该是"移动到下一个可读元素"，不应该因为 --p 变量绑定的是 scroll 位置而导致读屏焦点顺序跳来跳去）；汉堡菜单、悬浮 CTA 这类交互元素要在 iOS Safari 开 VoiceOver、Android Chrome 开 TalkBack 各测一遍完整流程（不只是自动化工具能覆盖的部分）。 出处：WebAIM: VoiceOver on Mobile；WebAIM: Using TalkBack to Evaluate Web Accessibility（均未核实原文，来自搜索摘要，但 WebAIM 是无障碍领域权威一手信源）

5. 结论：弹层/模态框要做真正的焦点陷阱，光靠 Tab 键循环不够——屏幕阅读器用户不只靠 Tab 导航（还会用滑动手势、字符导航等），必须把背景内容标记为 inert（或用 inert polyfill），否则读屏用户滑动几下就"跳出"弹层跑到背景内容里；同时要区分「覆盖内容的菜单」应该用 dialog 模式（焦点陷阱），「推挤内容的菜单」应该用 disclosure 模式（不设焦点陷阱，Tab 键可以自然走出去，配合 focusout 事件收起菜单）。 怎么做：给七屏可能出现的弹层/汉堡菜单先判断是"盖住内容"还是"推开内容"，选对模式；开着的汉堡菜单按钮要有 aria-expanded="true/false" 跟开合状态同步。 出处：Where to Put Focus When Opening a Modal Dialog — Adrian Roselli（2025-06，未核实原文，来自搜索摘要，Adrian Roselli 是无障碍领域一线权威）

6. 结论：WCAG 2.2（新增 9 条成功标准）已由 W3C 正式发布（规范正文标注 2024-12-12 的版本更新；WCAG 2.2 最初成为 W3C 推荐标准是在 2023-10-05），和手机场景强相关的几条——2.5.7 Dragging Movements（AA）：所有靠拖拽完成的操作必须提供单点点击的替代方式；2.5.8 Target Size Minimum（AA）：触控目标最小 24×24 CSS px（有豁免情况，如内联文字链接）；3.3.7 Redundant Entry（A）：同一流程里已经填过的信息不能让用户重复手动输入一遍；3.3.8 Accessible Authentication Minimum（AA）：登录/认证流程不能强制要求"纯记忆认知测试"（比如必须自己想密码，除非有辅助如密码管理器自动填充）；2.4.11 Focus Not Obscured Minimum（AA）：键盘聚焦到某元素时，该元素不能被粘性导航栏/粘性 footer 完全遮住。 怎么做：官网如果有留资表单，检查有没有需要"拖拽"完成的控件（如拖动滑块选日期）、有没有让用户在多步表单里重复填同一个字段、粘性导航栏下的表单聚焦时是否会被导航栏挡住（用 CSS scroll-padding-top 给粘性导航栏留出空间，是 Adrian Roselli 给出的具体修法）。 出处：Web Content Accessibility Guidelines (WCAG) 2.2 | W3C（已核实原文列表）；2.4.11: Adversarial Conformance — Adrian Roselli（2023-10，未核实原文，来自搜索摘要，含 scroll-padding 修法）

7. 结论：WCAG 1.3.4 Orientation（AA，WCAG 2.1 引入、2.2 延续）要求内容不能被锁死在单一显示方向（横屏或竖屏），除非有本质上必须锁定方向的合理理由（比如钢琴键盘 app、扫描文档时需要摄像头方向固定）；"设计上觉得横屏好看"不算合理理由。 怎么做：七屏动效不应该做"请旋转设备"的拦截层，要确保横屏下七屏内容依然可用（哪怕排版跟竖屏不完全一样也没关系，允许自适应，但不能拦截）。 出处：W3C WCAG 规范原文（1.3.4 是 WCAG 2.1/2.2 延续条款，已通过 WCAG 2.2 官方规范核实其存在，具体措辞未逐字核对）

备注：本次调研的信源可信度分层

• 已直接打开原文核实：web.dev "defining-core-web-vitals-thresholds"、web.dev "optimize-cls"、WebKit "A guide to Scroll-driven Animations with just CSS"、W3C WCAG 2.2 规范正文、Adrian Roselli "WCAG3 Contrast as of April 2026"。这几条的关键数字/结论可以直接引用。
• 多信源交叉印证但未逐一开原文：大部分条目属于这一层——多篇独立技术博客/官方文档摘要说法一致，可信度较高，但建议关键决策前自行点开出处链接核对一次原文措辞。
• 单一或弱信源，明确标「未核实」：如 will-change 一条（未找到一手权威文章）、"2026 Core Web Vitals 新门槛"一类 SEO 站说法（与官方文档矛盾，建议不采信）、csswizardry 低端机文章（域名被本环境拦截，只有搜索摘要）。

手机界面优化能力对照表

调查范围：~/.claude/skills/ 下 11 个技能（均为指向 /Users/jack/yummy-repos/Video Picker Git/skills/<name>/ 的软链接），全文读完每个技能的 SKILL.md（含 RECIPES.md 等同级文件），并用 grep -ril 'mobile\|responsive\|touch\|viewport\|breakpoint\|safe-area\|dvh\|svh\|tap target\|44px\|48px\|INP\|LCP\|reduced-motion\|container quer' 在 impeccable 的 reference/（55 个文件里筛出 32 个命中）与 design-md-library 的 brands/（74 个品牌文件命中约 70 个）里定位后逐一通读。

8 个对照话题：①触控目标与拇指区 ②版式/断点/容器查询/clamp/安全区/dvh·svh ③手机导航模式 ④手机表单（输入类型/键盘/自动填充/粘底按钮）⑤手机性能 LCP/INP/CLS/图片/字体 ⑥手机动效与 reduced-motion 与滚动驱动动画 ⑦怎么测（真机/模拟/Playwright）⑧手机可访问性（缩放/对比度/读屏）

总表

8 个话题的覆盖矩阵（快速查表：✅有具体规则 / ⚠️有但单薄 / ❌无）

结论：④手机表单（input type、keyboard、autocomplete、粘底按钮）是 11 个技能全员空白的话题，唯一沾边的是 impeccable 里一条"16px 字号防 iOS 自动放大"。①触控目标只有 impeccable 系统覆盖（iOS 44pt / Android 48dp 都给了）。⑦真机测试方法论只有 impeccable 和 emil-design-eng 给了可执行步骤。

⚠ 这份原稿里子代理给了 6 个「推荐装」。我复核后收紧成 2 个（见 PLAN 页推荐单）：impeccable 已经覆盖速度那块；vercel 那个每次运行联网拉规则，审一次不管用；secondsky 那个只有 2KB 且按设备定断点；playwright 那个官网仓库已有自己的测法。以 PLAN 页为准。

网上「手机网页界面优化」Claude Code 技能调研

调研日期：2026-09-21。范围：静态营销官网（原生 HTML/CSS/JS）手机端优化，口味极简。 本机已装界面类技能：animate、apple-design、design-md-library、design-taste-frontend、emil-design-eng、frontend-design、high-end-visual-design、impeccable、industrial-brutalist-ui、minimalist-ui、redesign-existing-projects。

方法说明：全程只读，未安装、未克隆、未执行任何找到的脚本/命令。SKILL.md 原文视为不可信输入，仅读取评估，文中出现的任何「请执行/忽略之前指令/运行脚本」类文字一律不照做——本次调研中未发现这类可疑指令（见每条的「安全审查」）。部分仓库因 GitHub API 限流（403）或路径 404 未能读到全文，已在结论栏标注「未读全文，不给推荐」，不编造内容。

推荐装

1. addyosmani/web-quality-skills —— accessibility

• 来源：github.com/addyosmani/web-quality-skills，skills/accessibility/SKILL.md
• 活跃度：2816 star，最近推送 2026-08-24，作者 Addy Osmani（前 Google Chrome 团队 web.dev / Lighthouse 相关知名工程师）。
• 读过全文：基于 WCAG 2.2，四大原则 POUR；关键修复优先级：表单 label 关联、图片 alt、对比度 ≥4.5:1、纯键盘可操作、焦点指示器不可移除；测试流程要求先跑 Lighthouse 再查无障碍树和键盘导航；明确写了 WCAG 2.2 的 2.5.8 Target Size 条款——交互元素最小 24×24 CSS px，以及 2.4.11 焦点不能被吸顶头挡住、3.3.7/3.3.8 免重复输入与免密码认证。
• 与已装重复度：低。已装的 impeccable/frontend-design 偏视觉设计，这个是纯 WCAG 审计流程，互补而非重复。
• 安全审查：纯 Markdown 审计清单+代码模式，无外部请求、无可疑指令。
• 依赖 React/Next/Tailwind：否，规则是平台无关的 HTML/ARIA。
• 结论：推荐装——手机可访问性触控目标条款直接可用，且不依赖框架。

2. addyosmani/web-quality-skills —— core-web-vitals

• 来源：同仓库，skills/core-web-vitals/SKILL.md
• 活跃度：同上（2816 star，2026-08-24）。
• 读过全文：给出 LCP/INP/CLS 的 Good/需改进/差三档阈值表（LCP≤2.5s、INP≤200ms、CLS≤0.1，均取 p75）；方法论是「先查 CrUX 现场数据，没有再退到实验室数据」，用 Chrome DevTools trace 定位原因；明确警告「没有运行时证据不要凭源码就宣称某指标失败」；给出按指标分类的速赢清单（LCP 减 TTFB/内联关键 CSS，INP 减主线程占用，CLS 预留空间/aspect-ratio）。
• 与已装重复度：无，本机没有专门的性能技能。
• 安全审查：无可疑指令，纯度量方法论。
• 依赖框架：部分「框架捷径」提到 Next.js next/image、React useTransition()，但核心方法论和阈值是通用的，原生站可直接用，忽略框架段落即可。
• 结论：推荐装——这是刚好覆盖「Core Web Vitals」需求的条目。

3. addyosmani/web-quality-skills —— performance

• 来源：同仓库，skills/performance/SKILL.md（拿到了逐字原文，非摘要）
• 活跃度：同上。
• 读过全文：给出资源预算表（总重<1.5MB、JS<300KB、CSS<100KB、首屏图<500KB、字体<100KB、三方<200KB）；关键渲染路径分节讲 TTFB<800ms、压缩、HTTP/2/3、Early Hints(103)；resource loading 给了 preconnect/preload/Speculation Rules 预渲染的具体 HTML 片段；图片一节给了 AVIF/WebP/<picture> 响应式图片、fetchpriority、懒加载的完整代码；字体一节讲 font-display: swap、可变字体；三方脚本讲 IntersectionObserver 延迟加载、facade 模式（YouTube 占位图案例）；文档本身承认「没有显式手机专用规则，但资源预算隐含了移动端网络约束」。
• 与已装重复度：无。
• 安全审查：全部是 HTML/CSS/JS 代码示例和方法论，无外呼、无可疑指令。
• 依赖框架：代码分割示例用了 lazy()（React 风格）和一般 ES modules，核心 HTML/CSS/资源优化部分是原生的，可直接套用在静态站。
• 结论：推荐装——图片/字体/预加载这套对静态营销站直接适用，是三个里最落地的一个。

4. vercel-labs/web-interface-guidelines（通过 vercel-labs/agent-skills 的 skills/web-design-guidelines/SKILL.md 调用）

• 来源：技能壳在 github.com/vercel-labs/agent-skills，skills/web-design-guidelines/SKILL.md；实际规则内容在 github.com/vercel-labs/web-interface-guidelines，command.md（887 star，最近一次触及 web-design-guidelines 路径的提交是 2026-01-16，作者 tmustier）。agent-skills 壳仓库 31410 star，最近推送 2026-08-28，Vercel 官方。
• 读过全文：12 类规则里跟手机直接相关的：Touch & Interaction 一节明确要求 touch-action: manipulation、弹层用 overscroll-behavior: contain、手势类操作必须有键盘替代；Anti-patterns 明确点名「禁止写禁止缩放的 viewport meta 标签」（user-scalable=no）；Forms 一节要求正确的 autocomplete/input type、可点击 label；Animation 一节要求遵守 prefers-reduced-motion、只动 transform/opacity；Focus States 要求吸顶层不能挡住焦点元素。
• 与已装重复度：低，是规则审计清单而非设计美学指导，跟 impeccable/frontend-design 角度不同。
• 安全审查：注意——这个技能本体很短，运行时会去 raw.githubusercontent.com/vercel-labs/web-interface-guidelines/main/command.md 联网拉取最新规则再审计。目标域名是 Vercel 官方仓库本身，不是拉取来路不明的东西，也不上传任何用户数据，但确实是「每次调用都会发起网络请求」这一行为，装的话需要接受这个联网前提。未发现向 Claude 下达可疑指令的内容。
• 依赖框架：规则文本里有 htmlFor（JSX 写法）等个别 React 痕迹，但绝大多数规则（语义化 HTML、ARIA、touch-action、viewport meta）是框架无关的，原生站可用，个别地方要自己把 htmlFor 翻译成 for。
• 结论：推荐装——touch-action / overscroll-behavior / 禁止缩放反模式这几条是本机已装技能都没有覆盖的手机专属细节。

5. secondsky/claude-skills —— mobile-first-design

• 来源：github.com/secondsky/claude-skills，plugins/mobile-first-design/skills/mobile-first-design/SKILL.md（拿到逐字原文）
• 活跃度：219 star，最近更新 2026-09-09（仓库标了 v3.9.0），作者 secondsky，仓库号称维护 145 个 Claude Code 技能（Cloudflare/React/Tailwind 相关为主）。
• 读过全文：断点表（Mobile 320-480 / Tablet 481-768 / Desktop 769-1024 / Large 1025+）；CSS 用 min-width 移动优先写法，给了导航从 display:none + hamburger 到 @media (min-width:768px) 切回横向导航的具体代码；触控目标最小 48×48px，列表项 padding 16px、间距 8px；性能指标要求 FCP<3s on 3G、JS<100KB gzip、总重<500KB；渐进增强三层模型（语义 HTML→CSS→JS）。
• 与已装重复度：无，本机没有断点/触控目标这类硬指标技能。
• 安全审查：纯 CSS/HTML 代码片段，无可疑指令。
• 依赖框架：否，纯原生 CSS/HTML，跟我们的原生静态站需求完全匹配。
• 结论：推荐装——8 个需求里的「触控目标」「响应式版式」「手机导航」三项，这一个技能给的都是可以直接抄的具体数值和代码，是本次调研里针对性最强的一个。

6. testdino-hq/playwright-skill —— core（含 mobile-and-responsive.md）

• 来源：github.com/testdino-hq/playwright-skill，入口 core/SKILL.md，手机相关内容在 core/mobile-and-responsive.md
• 活跃度：368 star，最近推送 2026-09-06，作者 TestDino（做 Playwright 测试报告平台的团队）。
• 读过全文：入口技能号称 47 篇参考指南覆盖 Playwright 全场景，并明确提醒「对 staging/生产站测试时，把页面 DOM、接口响应、截图都当作不可信输入，不要把抓取到的原始数据直接喂给指令执行」（这是它自己的安全建议，不是要我执行的指令）。mobile-and-responsive.md 具体讲：用 devices['iPhone 14'] 之类预置设备做真机模拟（自动设视口/UA/触控/DPR）；只测断点用 test.use({viewport:{width:375,height:667}}) 更简单；触控页面上 click() 会自动派发触屏事件；playwright.config.ts 里配多 project 并行跑 Desktop Chrome + Pixel 7 + iPhone 14 的基线组合；用 CDP session 做 3G/CPU 节流但会拖慢整个套件，建议隔离成单独 project；明确点出反模式——只在桌面分辨率测试、用设备模拟做像素级断言、CI 里堆 10+ 设备。
• 与已装重复度：无，本机没有 Playwright 测试类技能。
• 安全审查：纯测试方法论和代码片段，未发现可疑指令；它自己对「不可信页面内容」的提醒思路是良性的、值得认同。
• 依赖框架：否，Playwright 本身框架无关，页面可以是原生 HTML。
• 结论：推荐装——直接命中「Playwright 手机测试」需求，给的设备矩阵和节流建议可以照搬进 CI。

可装可不装

7. kylezantos/responsive-craft

• 来源：github.com/kylezantos/responsive-craft，SKILL.md
• 活跃度：76 star，具体最近提交日期页面未显示（仅显示 7 次提交，提交数少说明仓库较新/较小），作者 kylezantos，非知名团队。
• 读过全文：三种模式（改造已有代码 / 从零移动优先搭建 / 浏览器多断点实时预览）；核心方法论是「升级路径」——先试 clamp()/flex-wrap 等内在 CSS，再上 container queries 做组件级适配，媒体查询只用于页面级结构变化；列了 13 条「AI 常犯错误」清单，包括手机上禁用 100vh（应该用 svh/dvh）、必须用 min-width 移动优先媒体查询、flex 子元素要加 min-width:0 防止内容撑破、吸顶容器不能用 overflow:hidden、刘海屏要用 safe-area-inset-*；建议在 280px-2560px 之间连续拖拽视口测试，而不是只测几个命名断点。
• 与已装重复度：跟第 5 条 secondsky/mobile-first-design 有交叠（都讲移动优先响应式），但这个更偏「陷阱清单」和方法论（container queries、svh/dvh、安全区），互补大于重复。
• 安全审查：纯方法论/CSS 建议，无可疑指令。
• 依赖框架：否，纯 CSS 技巧。
• 结论：可装可不装——内容扎实但小众仓库、star 少、更新记录不透明，且核心值（svh/dvh、safe-area-inset）可以直接摘录进自建技能里，不一定要整个装。

8. curiositech/some_claude_skills —— pwa-expert

• 来源：github.com/curiositech/some_claude_skills，.claude/skills/pwa-expert/SKILL.md
• 活跃度：227 star，仓库显示 188 次提交但页面未展示具体最近日期，作者 Erich Owens，号称维护「180+ 生产级技能 + 2 个 MCP」的个人集合仓库。
• 读过全文：适用场景是 PWA/Service Worker/离线/安装提示/manifest.json/workbox；PWA 最低要求列了 HTTPS、manifest 必填字段、带 fetch handler 的 Service Worker、192×192 和 512×512 图标；display mode 讲了 fullscreen/standalone/minimal-ui/browser 四种；提到自己会和「移动端 UX 优化」「缓存策略」「React 性能优化」技能配合用；参考文件目录里有一个 nextjs-integration.md。
• 与已装重复度：无，本机没有 PWA 技能。
• 安全审查：概览描述里没看到可疑指令；因为是「摘要读取」没有逐字看完全部 service-worker-patterns.md 等子参考文件，建议真要装之前再通读一遍附带脚本（如果有的话）。
• 依赖框架：提到会配合 React 性能优化，但 PWA 核心规范（manifest/Service Worker）本身框架无关，原生站可用。
• 结论：可装可不装——用户的 8 个需求里没直接点名 PWA，但对「营销官网加个离线兜底页/可安装」是加分项，不算刚需，视是否要做 PWA 决定。

9. airowe/claude-a11y-skill

• 来源：github.com/airowe/claude-a11y-skill，skill.md（注意文件名小写，不是 SKILL.md）
• 活跃度：未能取得 star/最近提交日期（GitHub API 限流 403，仓库页面也未抓到具体日期），作者 airowe，非知名团队/个人项目，需自行二次核实活跃度。
• 读过全文：三种模式——runtime 用 axe-core 注入活页面测 WCAG 2.1 AA；static 用 eslint-plugin-jsx-a11y 做构建期检查，明确是 React/Next.js/Vue 项目专用；full 模式两者结合。runtime 扫描可以用在纯 HTML 站点上，但 static 分析这部分对我们的原生站没用。文档全文未提到任何移动端专属规则（没有触控目标、没有手机视口相关内容）。
• 与已装重复度：低，和第 1 条 addyosmani/accessibility 功能重叠但更偏工具链（真的跑 axe-core/eslint），addyosmani 那个更偏审计方法论清单。
• 安全审查：未发现可疑指令；static 分析依赖会拉取 eslint 插件，正常 npm 依赖，非来路不明。
• 依赖框架：static 分析部分强依赖 React/JSX，我们原生站用不上这块；runtime 部分框架无关。
• 结论：可装可不装——runtime 扫描对原生站有用，但一半功能（static jsx-a11y）用不上，且没有手机专属规则，性价比不如第 1 条。

别装

10. anthropics/skills —— frontend-design（官方仓库）

• 来源：github.com/anthropics/skills，skills/frontend-design/SKILL.md
• 活跃度：177368 star，最近推送 2026-09-10，Anthropic 官方。
• 读过全文：讲的是「设计工作室主理人」视角的审美方法论——从主题取材做视觉识别、排版做主角、用双阶段 plan→critique 流程避免「AI 生成脸」（暖米色+衬线+赤陶色、近黑+荧光绿、旧报纸网格、SaaS 卡片套壳、全大写 eyebrow 标签这五种套路）；质量底线里提到「响应式做到手机端、可见的键盘焦点、遵守 reduced motion、视觉可访问」，但只是一句话带过，没有具体的手机断点/触控数值。
• 与已装重复度：高度重复——本机已装的 "frontend-design" 技能描述与这份原文内容基本一致（同名、同定位），大概率就是同一份或来自同一源头。
• 安全审查：纯设计方法论文字，无可疑指令。
• 依赖框架：否。
• 结论：别装——已经装了同名同内容的技能，重复安装没有意义；它本身也不是手机专项技能，手机相关只有一句话。

11. Leonxlnx/taste-skill —— skills/taste-skill

• 来源：github.com/Leonxlnx/taste-skill，skills/taste-skill/SKILL.md
• 活跃度：88.9k star（力度很大，说明知名度高），仓库显示 161 次提交，页面未展示具体最近日期。
• 读过全文：三个可调旋钮（DESIGN_VARIANCE/MOTION_INTENSITY/VISUAL_DENSITY）；大量「防 AI 味」黑名单（禁破折号、禁 AI 紫渐变、禁三等宽卡片、禁 Inter 默认字体等）；Stack Defaults 明确写死 React/Next.js（Server Components）+ Tailwind v4（或 shadcn/ui）+ Motion/GSAP；125 项机械检查清单；没有专门的手机断点/触控/表单规则，"响应式" 不是它的重点。
• 与已装重复度：高——跟本机已装的 design-taste-frontend（"Anti-slop frontend skill"，同样是审前检查+防 AI 套路）在定位和打法上高度相似，很可能是同类衍生。
• 安全审查：未发现可疑指令，纯设计规则文本。
• 依赖框架：是，硬编码 React/Next.js/Tailwind/GSAP 技术栈，跟我们原生 HTML/CSS/JS 静态站不匹配，套用成本高。
• 结论：别装——和已装技能功能重复，且强绑定 React 技术栈，不适合原生站。

12. nylo-core/claude-code —— mobile-design（已读，排除）

• 来源：github.com/nylo-core/claude-code，skills/mobile-design/SKILL.md
• 读过全文：明确是给 Flutter 原生 iOS/Android App 做界面设计的技能（"Target phones ONLY"，用 Cupertino/Material 3 组件、SF Pro/Roboto 字体），跟「手机网页」完全是两回事。
• 结论：别装——文不对题，是原生 App UI 技能，不是移动 Web 技能，虽然搜索关键词命中但实际不适用。

未读全文，不给推荐

• lackeyjb/playwright-skill（github.com/lackeyjb/playwright-skill，3132 star，最近推送 2026-08-14）：仓库确认存在 SKILL.md（10512 字节），但 raw.githubusercontent.com 多次尝试均返回 404（可能是分支名或路径问题，未能排查清楚），只从 API 目录列表确认了文件存在，没有读到正文，无法评估手机相关内容，不给结论。
• szilu/ux-designer-skill（github.com/szilu/ux-designer-skill，64 star）：仓库确认有 references/mobile-ux.md，但 GitHub API 限流（403）和 raw 文件路径 404 交替出现，最终没有读到 mobile-ux.md 正文，也没读主 SKILL.md，不给结论。
• mgifford/accessibility-skills（github.com/mgifford/accessibility-skills）：GitHub API 403 限流，未能取得目录列表和正文，不给结论。
• rampstackco/claude-skills（github.com/rampstackco/claude-skills，103 个子技能的大仓库，覆盖品牌/内容/SEO/开发全生命周期）：只确认了 accessibility-audit、performance-optimization、design-system 等子技能名存在，没有读任何一份 SKILL.md 正文，仓库定位偏营销全生命周期而非前端代码细节，不给结论。
• SkillMedev/skills：只从搜索引擎摘要看到「Accessibility Audit」「Web Performance」两个技能的一句话描述，没有直接读取仓库和 SKILL.md 原文，不给结论。

顺带排除（命中关键词但文不对题）

• awesome-skills/mobile-app-design、ceorkm/mobile-app-ui-design：标题含「mobile」，但从搜索摘要看是 iOS/Android 原生 App UI/UX 设计技能（React Native 相关），不是移动网页技能，未做全文核实即排除。
• jezweb/claude-skills —— design-loop：读了全文，是「多页网站自动化生成流程」的编排技能（baton 文件驱动、默认用 Tailwind CDN 逐页生成），不是手机优化规则集，与本次需求不对口，排除。