Prettier中arrowParens配置详解与最佳实践
司空欣奥先看效果，再看代码
最近在重构一个老项目，团队里新来的同事提了个 PR，箭头函数写得五花八门：有的带括号，有的不带，还有的单参数加了括号但多参数又没加。我一看就头大，赶紧在 Prettier 配置里加上了 arrowParens，统一格式。亲测有效，从此再也不用在 Code Review 里反复写“请加括号”了。
简单说，arrowParens 就是控制 Prettier 在格式化箭头函数时，是否给单个参数自动加上括号。默认值是 "avoid"，也就是能省则省；但如果你跟我一样，觉得统一风格更重要，那就直接设成 "always"。
举个例子，下面这段代码：
const add = a => a + 1;
const multiply = (a, b) => a * b;用 arrowParens: "always" 格式化后，会变成：
const add = (a) => a + 1;
const multiply = (a, b) => a * b;是不是看着更整齐？尤其当你团队里有人喜欢写 (event) =>，有人写 event =>，混在一起简直灾难。统一加括号后，一眼就能看出这是个函数参数，阅读体验提升不少。
这个配置怎么加？核心代码就这几行
别整那些花里胡哨的，直接在你的项目根目录下找到或新建 .prettierrc 文件，加上这一行就行：
{
"arrowParens": "always"
}或者如果你用的是 JavaScript 配置（比如 prettier.config.js），那就这样写：
module.exports = {
arrowParens: "always",
};配完之后，记得在 VS Code 里装好 Prettier 插件，并设置保存时自动格式化（我一般都勾上 Format On Save）。改完配置，Ctrl+S 一按，满屏的箭头函数瞬间整齐划一，爽得很。
当然，如果你硬要保留默认行为，也可以显式写成 "avoid"，但我不建议。除非你团队有特别强的约定，否则“避免括号”在实际协作中很容易引发风格冲突。
踩坑提醒：这三点一定注意
别以为改个配置就万事大吉，我在这上面踩过好几次坑，分享给你避雷：
- 配置没生效？先查作用域：Prettier 的配置可能被上层目录的配置覆盖。比如你在一个 monorepo 里，根目录有个
.prettierrc，子项目也有一个，那子项目的优先级更高。但有时候你以为改了子项目的配置，其实编辑器还在读根目录的。建议在终端里跑一下npx prettier --check src/**/*.js看看实际用了哪个配置。 - 和 ESLint 冲突？关掉 ESLint 的格式规则：如果你同时用了 ESLint + Prettier，记得用
eslint-config-prettier关掉 ESLint 中所有和格式相关的规则。不然 ESLint 可能会报错说“Unexpected parentheses around single function argument”，而 Prettier 又坚持加括号，两边打架，保存一次格式化一次，无限循环。我之前折腾了半天才发现是这个原因。 - 旧代码别一次性全改：如果你在维护一个大项目，突然把
arrowParens改成"always"，然后全量格式化，Git diff 会爆炸——可能几百个文件都变了，PR 根本没法 review。建议分模块改，或者只在新代码里启用。我们团队的做法是：新文件强制用新风格，老文件逐步迁移，避免历史包袱拖累进度。
为什么我强烈推荐 always？
很多人觉得“单参数没必要加括号，省点字符”，但我觉得这种“省”毫无意义。现代 IDE 和 Git 都支持语法高亮和 diff，少两个括号对性能、可读性、文件大小几乎没影响。反而，统一风格带来的好处是实打实的：
第一，**减少认知负担**。看到 (x) 你就知道这是个参数，不用去数箭头左边有没有逗号来判断是单参还是多参。尤其是在复杂的链式调用里，比如：
data.map(item => item.id).filter(id => id > 0);如果写成：
data.map((item) => item.id).filter((id) => id > 0);一眼就能看出每个箭头函数的结构，不用停顿思考。
第二，**方便后续修改**。今天你写的是单参数，明天需求变了要加第二个参数，如果原来没括号，你得手动加括号；如果本来就有，直接加个逗号就行。小事情，但积少成多，开发效率就体现在这些细节里。
第三，**和 TypeScript 更搭**。TS 里经常要写类型注解，比如 (name: string) => void，这时候括号是必须的。如果 JS 也统一加括号，切换上下文时思维更连贯，不会因为风格差异而出错。
高级技巧：配合 Husky 做提交前校验
光靠编辑器格式化还不够保险，万一有人没装插件呢？我一般会在项目里加个 pre-commit hook，用 Husky + lint-staged，在提交前自动格式化并检查。
安装依赖：
npm install --save-dev husky lint-staged prettier然后在 package.json 里加：
{
"lint-staged": {
"*.{js,jsx,ts,tsx}": ["prettier --write"]
},
"husky": {
"hooks": {
"pre-commit": "lint-staged"
}
}
}这样，每次 git commit 之前，都会自动格式化改动的文件，确保进仓库的代码都是统一风格的。我试过好几次，有人本地没开自动格式化，但提交时被强制修正，久而久之就养成习惯了。
结尾：风格统一比“聪明”更重要
说实话，arrowParens 这个配置本身很简单，但背后反映的是团队对代码一致性的态度。我见过太多项目，因为“每个人有自己的写法”导致代码库像拼凑的补丁，新人进来光适应风格就得花一周。
所以我的建议很直接：**别纠结，直接设成 "always"，全团队统一，省心省力**。
以上是我踩坑后的总结，希望对你有帮助。这个技巧的拓展用法还有很多，比如结合 CI 做格式检查、和 EditorConfig 联动等，后续会继续分享这类博客。有更优的实现方式欢迎评论区交流！
暂无评论