find_by_sql不自动参数化，仅执行原始SQL字符串，所有注入风险由开发者承担；sanitize_sql仅安全处理值（如问号占位符），字段名等结构部分必须白名单校验。
find_by_sql 本身不提供自动参数化，所有风险都由你承担——它只负责执行传入的字符串，不管里面有没有 ' OR 1--。
用 sanitize_sql 处理动态值，但字段名必须白名单
如果你非得拼 SQL（比如查 JSONB 字段、用窗口函数），ActiveRecord::Base.sanitize_sql 是唯一靠谱的“消毒”方式，但它只处理值，不碰字段名或结构关键词：
-
sanitize_sql(["SELECT * FROM users WHERE status = ?", params[:status]])✅ 安全：问号会被connection.quote转义 -
sanitize_sql(["ORDER BY #{params[:sort]}"])❌ 危险：字段名未校验，params[:sort]是"email; DROP TABLE users--"就完蛋 - 排序方向、分组字段、JOIN 表名、HAVING 条件——这些都得靠代码逻辑拦截，比如
allowed_sorts = %w[name email created_at]; raise if !allowed_sorts.include?(params[:sort])
别用 to_sql + find_by_sql 假装安全
有人以为套一层 Arel 就万事大吉：sql = User.arel_table.where(User.arel_table[:email].eq(params[:email])).to_sql; User.find_by_sql(sql)。这毫无意义：
-
to_sql输出的是纯字符串，find_by_sql接收后直接交给数据库执行，不识别任何绑定上下文 - 日志里会看到 raw SQL，没有任何参数占位符痕迹
- 等价于手写
"WHERE email = '#{params[:email]}'"，只是多绕了一步
能不用 find_by_sql 就别用
绝大多数场景，where、joins、select 配合 ? 占位符或命名绑定完全够用：
-
User.where("age > ? AND status IN (?)", params[:min_age], params[:statuses])✅ 自动转义 -
User.joins(:posts).where(posts: { published: true }).select("users.*, COUNT(posts.id) as post_count")✅ 结构清晰，无字符串插值 - 只有极少数情况（如 PostgreSQL 的
jsonb_path_query、复杂 CTE）才真需要find_by_sql，此时务必把结构部分（表名、函数名、关键字）硬编码，只让值走sanitize_sql
最常被忽略的点：SQL 注入不是“值没转义”导致的，而是“结构可被用户控制”——字段名、排序方向、GROUP BY 列、UNION 后的表名……这些从不进参数化流程，也永远不会被 sanitize_sql 碰到。
