第 10 章 认识一个仓库：拿到新项目先看什么

打开一个陌生仓库（包括我们自己几个月没碰的老项目），从第一行代码读起是最低效的方式。老手有一套开箱顺序，五分钟建立全局感。

先读 README——项目的说明书：它是什么、怎么跑起来、怎么参与。一个仓库对人友好不友好，README 见分晓。再看 package.json——第一册说它是购物清单，这里补上它的另一半身份：快捷按钮面板。里面的 scripts 区写着类似 "dev": "next dev" 的条目，意思是：敲 npm run dev，等于替你敲后面那串长命令。npm run dev 的真相就这么朴素——它是项目作者预设的快捷键，dev 通常是"本地跑起来"，build 是"打包成品"。顺带一条铁律：clone 下来的项目第一件事跑 npm install——照购物清单把货搬齐（node_modules 不进 Git，得自己装），清单变了也要重跑。

然后扫一眼目录结构：src 是源代码本体，public 是原样上线的静态文件（图片、图标）。根目录那一排配置文件，认脸即可，不必细读：tsconfig.json 是 TS 的规矩（第三册见），tailwind.config 是样式的规矩，vite.config 或 next.config 是构建的规矩，.github/workflows/ 里藏着自动流水线（第一册说的 CI/CD 本尊），LICENSE 声明开源许可。它们像家电说明书——知道在哪，用到再翻。

单独点名一个宝贝：.env.example。它是环境变量口袋的清单模板——列出这个项目需要哪些钥匙，但不含钥匙本身（所以它可以进 Git）。拿到新仓库跑不起来，八成是没照着它配出自己的 .env。看它，是"这个项目依赖哪些外部服务"的最快答案。

关键领悟

读仓库的顺序是 README → package.json → 目录 → .env.example，最后才是代码。全局感先于细节。

试一试

按这个顺序把我们的主仓库重新"开箱"一遍，每遇到一个不认识的配置文件，问 AI 一句："它管什么规矩？"