Buffalo 框架本身不提供原生 LIKE 查询封装，需依赖底层数据库驱动和安全 SQL 构建；正确做法是预处理用户输入（转义 %、_ 和反斜杠）、使用 ESCAPE 子句，并优先考虑全文检索替代低效模糊查询。
Buffalo 框架本身不提供原生的 LIKE 查询语法封装，它依赖底层数据库驱动（如 github.com/go-sql-driver/mysql 或 lib/pq）和 SQL 构建方式，所以“怎么用 LIKE”本质上是你怎么安全、高效地写带通配符的 SQL —— 而不是调用某个 Buffalo 特有函数。
Buffalo 中直接拼接 LIKE 条件的风险
很多人第一反应是：db.Where("name LIKE ?", "%"+keyword+"%").All(&users)。这看似可行，但容易踩坑：
- 用户输入含
%或_时，会意外扩大匹配范围（比如搜100%，%被当通配符） - 没做
ESCAPE处理，无法区分字面量和通配符 - 若 keyword 来自 HTTP 参数且未 trim，前后空格会导致查不到结果
- MySQL 中
LIKE '%xxx'无法走索引，性能随数据量陡增
正确构造带转义的 LIKE 查询（MySQL 场景）
MySQL 支持 ESCAPE 子句，推荐用反斜杠 作为转义字符。Buffalo 的 db.Where 允许你传入原始 SQL 片段，只要参数绑定安全即可：
假设你要查 users.name 包含用户输入的 keyword（支持字面量 % 和 _）：
escaped := strings.ReplaceAll(keyword, ``, `\`)
escaped = strings.ReplaceAll(escaped, `%`, `%`)
escaped = strings.ReplaceAll(escaped, `_`, `_)
db.Where("name LIKE ? ESCAPE '\'", "%"+escaped+"%").All(&users)
注意三点：
Buffalo框架 1.0.1
下载
Buffalo框架 1.0.1 版本源码包下载，适合需要错误处理改进、依赖更新、render.Download 注释和 request logger 调整的 v1 项目。
- 先双写反斜杠（防止 Go 字符串解析吃掉一个），再转义
%和_ -
ESCAPE '\'中的\是 SQL 层看到的单个，不能写成'' - 仍要避免前导
%（如%xxx），否则索引失效；若业务必须支持前缀模糊，考虑加前缀索引或改用全文索引
PostgreSQL 用户注意 ESCAPE 语法差异
PostgreSQL 同样支持 ESCAPE，但默认不把反斜杠当转义符，需显式声明。而且它的 ILIKE 不区分大小写，比 MySQL 更常用：
db.Where("name ILIKE ? ESCAPE '\'", "%"+escaped+"%").All(&users)
关键区别：
- PostgreSQL 中
ILIKE是标准做法，MySQL 没这关键字 - PostgreSQL 的
ESCAPE必须跟在ILIKE后，不能省略 - 如果字段建了
text_pattern_ops索引，ILIKE 'xxx%'可走索引；但ILIKE '%xxx'依然不行
更健壮的替代方案：用 full-text search 替代 LIKE
当模糊查询变成高频、多字段、高并发需求时，硬扛 LIKE 会拖垮数据库。Buffalo 项目可集成外部服务：
- 对小数据量（to_tsvector +
@@操作符，比ILIKE快且支持词干匹配 - 对大数据量，用 ElasticSearch 或 Meilisearch，通过 Buffalo 的
render.JSON直接透传查询结果，避开数据库瓶颈 - 不要在 Buffalo 的
Action里写复杂字符串拼接逻辑——把转义、分页、缓存等抽成独立 service 函数，方便测试和复用
真正难的不是写那行 WHERE name LIKE ...，而是判断这个查询是否该出现在数据库里。很多团队卡在“功能能跑通”，却没意识到 LIKE '%keyword%' 在百万级表上一次查询就吃掉 200ms —— 这种性能债，上线后才爆出来最麻烦。
