主题
高级资深前端面试题 · Vue 组件化开发与设计
如何在 Vue 组件库中系统性实现可访问性？
这道题不只考 API 记忆，还考察你能否把 Vue3 的设计思想、运行机制、工程边界和团队落地连接起来。
面试官想考什么
- 你能否先定义问题边界？
考察是否知道这项能力解决什么问题，以及它不负责什么。 - 你能否解释 Vue3 的机制或设计取舍？
考察能否从组件、编译器、运行时、浏览器和工程系统多个层面建立因果链。 - 你能否把方案落到大型项目？
考察可维护性、可扩展性、性能、类型、测试、兼容和发布治理意识。 - 遇到复杂边界或线上故障怎么办？
考察是否能设计降级、观测、回滚和验证闭环，而不是只给理想路径。
一句话回答
text
可访问性要从语义 HTML、键盘交互、焦点管理、ARIA 状态、颜色对比度和自动化测试共同保证，而不是给组件加几个 aria 属性。面试回答详解
这道题的高级回答重点是把概念放回工程上下文：先说它解决的问题，再解释关键机制，最后说明适用边界、失败模式和验证方法。
1. 语义优先\n\n能用 button、label、input、dialog、ul/li 等原生语义解决的问题，不要用 div 加 click 重新发明交互。\n\n### 2. 焦点管理\n\nDialog、Menu、Combobox、Tabs 等组件要定义焦点进入、移动、退出和销毁后的回收策略。\n\n### 3. 状态同步\n\naria-expanded、aria-selected、aria-disabled、aria-controls 等状态必须和真实交互状态同步，不能只写静态字符串。\n\n### 4. 质量验证\n\n键盘测试、屏幕阅读器抽查、axe 等自动化检测、对比度检测和真实用户反馈要纳入组件库 CI。
可直接背诵的 30 秒回答
text
我会从原生语义出发设计组件，再补键盘和焦点模型、动态 ARIA 状态、对比度和自动化检查；可访问性是组件行为契约，不是最后追加的属性。扩展知识
从概念到工程
text
稳定契约 -> 明确状态边界 -> 可组合实现 -> 可观测验证 -> 兼容演进常见误区
- 把 Vue 的语法糖当成完整的架构方案。
- 只讨论正常路径，不讨论异步、卸载、失败、SSR 或大数据量。
- 只看局部性能，不看调用方复杂度、测试成本和升级成本。
- 用内部实现细节作为公共契约，导致后续重构困难。
面试官追问链
追问一：为什么只加 aria-label 不够？\n\n- 考察点：面试官想确认你是否掌握这个方案的边界。\n- 回答方向：ARIA 不能补救错误的交互模型和焦点流，语义、键盘、状态和焦点必须整体设计。\n\n### 追问二：如何测试焦点回收？\n\n- 考察点：面试官想确认你是否掌握这个方案的边界。\n- 回答方向：记录打开前 activeElement，关闭后验证焦点回到合理目标，并覆盖组件被卸载的异常路径。\n\n### 追问三：无障碍会不会影响开发效率？\n\n- 考察点：面试官想确认你是否掌握这个方案的边界。\n- 回答方向：早期约束会减少后期返工；组件库把行为沉淀后，业务开发反而更快。
推荐阅读
- Props\n- Component Events\n- Slots\n- Fallthrough Attributes\n- Provide / Inject\n- Composables\n- Accessibility\n- Testing