前端知识库前端技术误区与验证
把框架、性能、异步、工程交付和项目技术表述中的常见误区改写成可验证的检查项。
前端技术误区与验证
整理来源：
第四篇 - 面试高频踩坑解析.pdf、第五篇 - 面试利器之前端技术架构设计实操.pdf。仅保留可以通过代码、文档或实验验证的技术判断；不采用年龄、学历等偏见，也不复述课程和报名话术。
1. “列出一串库名”不等于架构
把 Router、状态库、UI 库、国际化和测试工具罗列出来，只能说明依赖，不说明系统如何变化。至少要补四件事：
- 业务边界：页面、用例、数据访问和基础设施谁负责什么。
- 依赖方向：哪些模块可以被替换，哪些接口是公共契约。
- 失败路径：网络失败、权限变化、旧版本数据和发布回滚如何处理。
- 验证方式：用哪组测试、指标或故障演练证明选择有效。
架构图可以很小，但每条箭头都应能对应到代码目录、接口或测试。参见前端项目架构与选型。
2. 框架和状态管理的常见误解
“流行框架一定适合项目”
框架选择应由运行环境、团队能力、渲染/SEO、生态兼容和迁移成本共同决定。回答“为什么选 Vue/React”时，先说约束和替代方案，再说具体 API；不能把社区热度当作性能或稳定性的证明。
“文件系统路由自带权限”
文件系统路由只负责生成或组织路由表。鉴权仍需服务端授权、客户端导航守卫、过期会话处理和可观测错误；隐藏菜单不能阻止直接访问接口。
“全局 store 能解决所有状态”
服务端数据、页面 UI、URL、表单草稿和会话凭据的生命周期不同。全部塞进一个 store 会造成缓存失效、竞态和隐私边界混乱。先写状态所有权，再决定局部状态、请求缓存或全局 store。
“组件库只要复用视觉”
公共组件还要稳定 API、键盘/焦点行为、类型声明、主题令牌、SSR 和版本迁移。只测默认截图而不测受控状态和无障碍，无法证明组件可复用。
3. 异步和 Node.js 的误区
“单线程等于只能做一件事”
JavaScript 主线程按事件循环执行回调；I/O 可以由运行时和操作系统并行推进，Worker/线程池也能承担部分 CPU 工作。单线程并不意味着没有并发，也不意味着 CPU 密集任务不会阻塞页面。
“加上 async 就不会阻塞”
async 只改变 Promise 契约；同步的 JSON 解析、复杂循环和大 DOM 更新仍在当前线程执行。长任务应拆分、移到 Worker 或降低输入规模，并用 Performance 工具验证。
“Promise.all 就是并发限制器”
Promise.all 会立即启动已创建的任务，并不提供队列上限、取消、超时或公平性。请求突发需要有界调度器，且在 finally 中释放槽位；错误策略（首错终止还是收集全部结果）要写进契约。可参考受限并发 Scheduler。
4. 性能表述的误区
“优化百分比”可以脱离基线复述
没有设备、网络、数据量、版本和测量方法，单次收益数字不能迁移到另一个项目。可靠的性能说明至少包含：
- 优化前后的同一场景、样本和版本；
- 指标定义（例如 LCP、长任务、包体、错误率）与分位数；
- 影响范围、回归检查和未解决的成本；
- 无法测量时明确写成假设，而不是事实。
“Tree Shaking 会自动删除所有无用代码”
Tree shaking 依赖静态模块分析和准确的副作用声明。错误标记 sideEffects: false 可能删除样式注入、全局注册或 polyfill；反过来把整个包标成有副作用又会损失优化。用真实消费者安装产物并检查 CSS、类型和入口。
“首屏慢只要换构建工具”
先区分服务器响应、资源下载、脚本执行、样式/字体、数据请求和渲染长任务，再决定预加载、拆包、缓存、SSR 或降级。优化方案要能由 Web Vitals、资源瀑布和版本标识复盘。
5. 工程交付和发布的误区
“CI/CD 等于每次提交直接上线”
持续交付需要自动化检查、产物追溯、分批发布、监控和回滚；发布频率不是质量标准。至少区分必须阻断的类型/Lint/测试错误与可观察告警，并为高风险变更保留人工确认或小流量验证。
“有测试就代表质量有保障”
测试应覆盖契约和风险：单元测试状态转移，组件测试键盘/焦点/错误，E2E 测真实导航和权限，构建检查产物入口，发布后监控异常。只测 happy path 或只截默认页面，无法覆盖故障边界。
“配置继承能自动消除治理问题”
共享 tsconfig/ESLint 配置只能统一默认约束，不能替代包边界、迁移基线和版本锁定。老项目应采用“不能新增错误”的增量门禁，记录豁免责任和期限，避免把 any、忽略目录或禁用规则变成永久垃圾桶。
6. 技术经历如何保持可验证
技术表述不必堆砌“精通”等级，也不应写入无法解释的项目细节。更可靠的记录方式是：
背景/约束 -> 个人负责的决策和实现 -> 失败边界与取舍
-> 可复现的验证方式 -> 对用户、维护或稳定性的影响
例如，与其写“精通性能优化”，不如说明“定位到某类长任务，拆分更新并加入回归样例，发布后按版本观察长任务分位数”。涉及业务机密时可隐去具体值，但要保留指标定义、比较方法和个人贡献；不要用没有来源的薪资、排名或收益数字替代证据。
7. 误区到验证的映射
| 判断 | 最小验证 |
|---|---|
| 分层确实隔离变化 | 替换一个适配器，领域测试无需修改 |
| 并发上限有效 | 任务工厂记录峰值 in-flight，并覆盖失败/取消 |
| Tree shaking 安全 | 安装打包 tarball，检查 ESM/CJS、类型和 CSS |
| 性能优化有效 | 固定设备、网络、数据和版本，比较同一指标分位数 |
| 灰度可回滚 | 用版本标识触发故障，确认告警、止血和旧产物入口 |
| 组件可复用 | 运行受控/非受控、键盘、焦点、SSR 和主题回归 |
最后再回答“用了什么技术”：先给结论和约束，再给机制、证据和边界。这样既能接住 PDF 中的高频追问，也不会把宣传口径误当成工程事实。