Prettier 会为 while 等条件语句中的赋值表达式（如 a /= b）自动添加额外一层圆括号，即把 while (a /= b) 格式化为 while ((a /= b))，这是有意为之的设计，旨在显式提示开发者此处是赋值而非比较，增强代码可读性与安全性。
prettier 会为 `while` 等条件语句中的赋值表达式（如 `a /= b`）自动添加额外一层圆括号，即把 `while (a /= b)` 格式化为 `while ((a /= b))`，这是有意为之的设计，旨在显式提示开发者此处是赋值而非比较，增强代码可读性与安全性。
在 JavaScript 中，while (a /= b) 和 while ((a /= b)) 语义完全等价，运行结果一致。但 Prettier 主动插入外层括号，并非 bug，而是遵循社区广泛采纳的安全编码惯例：用双重括号明确标识“此处确为赋值操作”，以规避 = 与 === 的误写风险。
这一行为源自 ESLint 的 no-cond-assign 规则设计理念——该规则默认禁止在条件中直接使用赋值（因易引发逻辑错误），但允许通过外层括号显式“豁免”，即 if ((x = getValue())) 是被接受的合法写法。Prettier 将此约定内化为格式化策略，对所有条件语句中的赋值表达式（包括 while、if、for 的测试表达式）统一加括号：
// 输入（未格式化）
if (x = y) { /* ... */ }
while (count--) { /* ... */ }
for (let i = 0; i <blockquote><p>✅ 注意：该行为 <strong>不可通过 .prettierrc 配置关闭</strong>。Prettier 不提供 disableExtraParenthesesInCondition 类似选项——它属于核心格式化逻辑的一部分，与 bracketSpacing 或 arrowParens 等可配项不同，属于硬编码的语义强化策略。</p></blockquote><p>若团队确有强一致性要求（例如严格遵循某份内部编码规范禁止双括号），需注意：</p>
- 不建议禁用该行为：它本质是静态分析友好的“视觉断言”，能降低 Code Review 时对 =/==/=== 混淆的误判概率；
- 替代方案有限：可考虑在 ESLint 中启用 no-cond-assign: ["error", { "checkWhenStatement": false }] 并配合 eslint-config-prettier 屏蔽冲突规则，但 Prettier 仍会保留双括号——格式化与 linting 应各司其职；
- 关键原则：Prettier 的设计哲学是“最小配置、最大共识”。此类看似冗余的括号，实则是对 JS 历史痛点（赋值误写为相等判断）的主动防御，已成现代前端工程实践的事实标准之一。
因此，当你看到 while ((a /= b))，请将其视为 Prettier 对代码健壮性的一次静默守护，而非格式瑕疵。
