SublimeLinter-rubocop默认仅做代码风格与反模式检查，不执行静态安全分析；需手动安装rubocop-security、在.rubocop.yml中显式require并启用Security类规则，且SublimeLinter配置须指定bundle exec rubocop路径，缺一不可。

先说一个很多人都会踩的坑：SublimeLinter-rubocop 确实能跑静态安全分析，但默认情况下，它只检查代码风格和常见反模式。

也就是说，它主要帮你看缩进、命名这类问题。

如果要检测 SQL 注入、命令执行、参数污染这些真正的安全问题，必须手动补齐插件和规则。否则，编辑器里不会弹出任何安全警告。

下面拆开来说，每一步都不能少。

rubocop-security 插件必须显式启用

RuboCop 本身不内置安全检查能力，rubocop-security 是一个独立的 gem。

它需要额外安装，并且要在配置中明确声明，才能生效。

操作分几步：

• 全局安装：直接 gem install rubocop-security

• 项目级更稳妥的方法：在 Gemfile 里加上 gem 'rubocop-security', require: false，然后 bundle install

• 配置文件 .rubocop.yml 里必须写明扩展引用：

  require:
    - rubocop-security

• 否则 SublimeLinter-rubocop 完全感知不到这些规则，编辑器里自然不会报任何安全相关警告

这一步看起来简单，但很多人会漏掉 require。

一旦漏掉，插件就等于白装了。

默认 .rubocop.yml 不含安全规则

刚生成的 .rubocop.yml，比如用 rubocop --init 创建的版本，通常只启用了 Layout、Style、Metric 等常规类目。

Security 类规则全部处于禁用状态。

你需要检查配置里是否有 Security/ 开头的条目。

比如 Security/Eval、Security/YAMLLoad。

如果没有，就要手动添加，并设为 Enabled: true：

Security/Eval:
  Enabled: true

还有一个细节要注意：部分规则，如 Security/MarshalLoad，在 Rails 7+ 默认已启用。

但老项目或者自定义配置里，常常会遗漏这些规则。

所以，最好逐条核对一遍。

SublimeLinter-rubocop 不自动识别 bundle exec

这是最隐蔽的一个坑。

SublimeLinter-rubocop 默认调用的是全局 rubocop 命令，但项目依赖的 rubocop-security 很可能只装在 bundle 环境里。

这时你通常会遇到经典报错：cannot load such file -- rubocop-security。

解决办法是，在 Sublime 的 SublimeLinter.sublime-settings 中显式指定执行路径：

"rubocop": {
  "executable": ["bundle", "exec", "rubocop"]
}

注意：不要只填 ["bundle", "exec"]。

后面必须把 rubocop 作为第三个参数写出来，否则不生效。

rails/rails_best_practices 规则不兼容 rubocop-security

有些团队喜欢混用 rails_best_practices 或自定义 cop。

但这些工具和 rubocop-security 之间可能存在冲突。

典型问题包括：

• Security/MissingCSRFToken 和 Rails/OutputSafety 可能对同一行代码重复报错，产生噪音

• 更严重的是，某些旧版 rubocop-rails（配合 rubocop-security > 2.0）会因为 AST 解析差异导致崩溃

实操建议如下：

• 统一使用 rubocop-rails ≥ 2.16

• 统一使用 rubocop-security ≥ 2.20

• 在 .rubocop.yml 顶部把两个扩展都 require 进来：

  require:
    - rubocop-rails
    - rubocop-security

结论

真正起作用的安全检查，靠的是你手动把 rubocop-security 塞进 bundle、写进配置、再告诉 SublimeLinter 去哪里找它。

漏掉任何一环，编辑器里就只剩风格提示，跟安全二字毫无关系。