RuboCop 和 Rufo 有什么区别？代码检查与格式化工具对比
RuboCop 是全能 Linter 管风格与缺陷，Rufo 只做格式化不管对错。本文从定位、配置、转换效果、编辑器集成与性能对比两者，讲清现代 Ruby 工具链的正确组合。
RuboCop 和 Rufo 不是竞争关系而是分工关系：RuboCop 是 Linter，管代码风格、复杂度和潜在 bug；Rufo 是格式化器，只管缩进、空格、换行的统一。现代实践是用 RuboCop（或其零配置封装 Standard）一站搞定——它已内置格式化能力，单独引入 Rufo 的场景越来越少。
定位差异：裁判 vs 美容师
RuboCop 检查代码时会"评判"你：方法太长、命名不规范、有可疑写法、缩进错误——它背靠几百条 cop 规则，是代码质量的守门员。Rufo 完全没有意见：你给什么代码，它只负责重排格式（缩进、空行、折行位置），不评价好坏、不提供修正建议。一个是裁判，一个是美容师。
同一代码的处理差异
def calc( a,b )
result=a+b
return result
end
Rufo 处理后——格式规整，但糟糕的命名和多余 return 原样保留：
def calc(a, b)
result = a + b
return result
end
RuboCop 处理后——除了格式化，还会指出：Style/MethodDefParentheses、Style/RedundantReturn（Ruby 不需要显式 return）、Naming/MethodParameterName 等，-a 一并修正。
配置与使用
Rufo 的配置项极少（这正是它的卖点）：.rufo 文件里几个选项，争议为零。RuboCop 的 .rubocop.yml 可以精细控制每条规则——自由度高，也意味着团队要花时间达成配置共识。
rufo . # 就地格式化
rubocop -a . # 检查并自动修正
编辑器与团队工作流
两者的编辑器支持都成熟（保存时自动格式化）。团队工作流的差异在于：Rufo 只能保证"代码看起来一致"，无法执行团队约定（如禁用某种写法）；RuboCop 的规则集可以把团队约定变成 CI 里的硬约束。需要"管起来"的团队选 RuboCop，只想"看起来整齐"的个人项目用 Rufo 也无可厚非。
性能与边缘情况
Rufo 只做格式化，速度在大代码库上占优；RuboCop 全规则扫描较慢（--parallel 可缓解）。边缘情况上，Rufo 对某些非常规语法（复杂链式调用、heredoc 嵌套）的格式化策略更保守稳定，而 RuboCop 的 Layout cop 偶尔与开发者的刻意排版冲突——这也是 Standard gem 干脆关闭大部分 Layout 配置项的原因。
现代工具链的建议
2026 年的务实方案：RuboCop 一把抓（Layout + Style + Lint + Metrics 全开），或 Standard（RuboCop 零配置版，格式争议归零）。Rufo 更适合作为"只想格式化、不想被评判"场景的单点工具——例如把遗留代码库快速排版统一，但不做任何规则强制。
常见问题（FAQ）
Q：RuboCop 和 Rufo 能一起用吗？
能，但容易打架：RuboCop 的 Layout cop 与 Rufo 的格式化结果可能不一致，互相把对方的输出当违规。要混用就关掉 RuboCop 的全部 Layout 规则，格式化交给 Rufo——但既然 RuboCop 自带格式化，多数团队直接单用 RuboCop。
Q：Rufo 支持配置缩进风格吗？
支持基础配置（缩进宽度、引号风格、链式调用折行方式），但选项刻意保持最少——Rufo 的理念是"格式争议用零配置终结"，想要高度定制就用 RuboCop。
Q：格式化会弄乱 git blame 吗？
会，一次性全库格式化会让 blame 指向格式化提交。对策：把格式化提交哈希加入 .git-blame-ignore-revs（GitHub 原生支持），blame 自动跳过该提交。
参考文档
本文依据公开文档整理，示例需按项目依赖版本验证；不将文档中的性能描述视为本项目实测结果。
