刚接手一个新项目，打开代码仓库第一眼看到的不是炫酷的功能界面，而是一堆目录和配置文件。这时候，最想翻的是什么？不是源码，也不是设计图，而是那份藏在根目录下的 README.md —— 或者更具体点，是里面的 FAQ 章节。
为什么框架文档总要有 FAQ？
你有没有遇到过这样的问题：环境装好了，依赖也拉了，一运行就报错 “Module not found”。查了一圈，发现只是某个插件需要额外注册。这种“踩坑”经历，每个人都有。而 FAQ 的存在，就是把前人踩过的坑，变成一条条简短的回答，省得后来人再绕路。
它不像 API 文档那样系统，也不像教程那样循序渐进，但它快、准、狠。比如：
Q: 启动时报错 "Cannot find module 'babel-core'"
A: 请确认已安装 @babel/core 而非旧版 babel-core，v7+ 版本已迁移到 scoped 包。
FAQ 不是摆设，得会用
很多人看文档，习惯从头读到尾。其实更高效的方式是：先扫一眼 FAQ，尤其是 “Common Issues” 和 “Troubleshooting” 这类小节。就像去修车前先问问师傅最近是不是同款车型都出了啥毛病，能省下不少时间。
有些框架的 FAQ 甚至藏着“彩蛋”。比如 Next.js 的 FAQ 里提到，如果静态导出失败，可能是动态路由没提供 getStaticPaths。这条信息藏得深，但一旦遇到，直接救命。
写好 FAQ，也是技术活
作为团队里的老手，别觉得写 FAQ 是小事。一条清晰的问答，能减少十次群里的重复提问。写的时候要代入新手视角，别用“显然”“如前所述”这种词。直接说清楚现象、原因、解法。
Q: 页面刷新后路由失效（404）
A: 在生产环境中使用 history 模式时，需确保服务器将所有路由指向 index.html。
这类问题，光看代码逻辑可能想破头，但有了 FAQ，三秒定位。
别只依赖官方 FAQ
社区的力量往往更强。GitHub 的 Issues 页面，其实是另一种形式的 FAQ。搜一下错误关键词，很可能早就有人提过类似问题，还附了解决方案。甚至有些开源项目的 Wiki 或第三方博客，整理得比官方还全。
下次遇到怪问题，别急着重装 node_modules，先去翻翻 FAQ，不管是官方的还是民间的。那几行字，可能就是你下班前能准时走的关键。