Echo框架不防SQL注入因其仅作HTTP路由，不干预数据库层；须用database/sql参数化查询，禁用字符串拼接，动态标识符需白名单校验，日志与子查询等边界点同样需防护。
Go 的 Echo 框架本身不处理 SQL 安全，db.Query 或 db.Exec 直接拼接字符串就等于把数据库钥匙交给用户——哪怕只用一次 fmt.Sprintf("WHERE name = '%s'", input)，就可能被 admin' OR '1'='1 打穿。
为什么 Echo 默认不防 SQL 注入
Echo 只是 HTTP 请求路由器，它把 GET /search?q=xxx 交给你写 handler，但不会拦住 q 里的恶意字符进 SQL。它不碰数据库层，也不自动转义、不封装参数化逻辑。你用 database/sql + lib/pq 或 mysql 驱动，就得自己确保每个 Query 调用都走参数绑定。
- 框架没内置 ORM，
echo.New()启动的服务默认裸奔 - 模板渲染用
html/template可防 XSS，但对 SQL 注入完全无效 -
c.Param("id")或c.QueryParam("q")返回的都是原始字符串，无清洗、无类型约束
在 Echo 中正确使用 database/sql 参数化查询
Go 标准库 database/sql 原生支持参数化，但占位符因驱动而异：lib/pq（PostgreSQL）用 、；mysql 驱动用 ?；sqlite3 两者都认。硬写死一种写法会锁死数据库选型。
Echo框架 5.1.0
下载
Echo框架 5.1.0 版本源码包下载，适合关注 RealIP 行为变化、StartConfig.Listener、NewDefaultFS 和观测性中间件入口的开发团队。
- 查单条用户：用
db.QueryRow("SELECT id, name FROM users WHERE email = $1", email)，不是"...WHERE email = '" + email + "'" - 模糊搜索（如
LIKE）：先拼接通配符到变量里，再传参：pattern := "%" + strings.TrimSpace(q) + "%"，然后db.Query("...WHERE name LIKE $1", pattern) - IN 查询不能直接参数化多个值，需动态生成
$1,$2,$3占位符串，再db.Query(..., args...)展开 - 永远不用
addslashes或正则替换单引号——Go 没这函数，且这种“手动转义”在宽字节或编码绕过场景下已失效
动态表名/列名/ORDER BY 怎么办
这些无法用参数化，因为 SQL 解析器要求它们是标识符而非值。例如 SELECT * FROM ? 或 ORDER BY ? 会报错 ERROR: syntax error at or near "$1"。
- 白名单校验是唯一可靠方式：定义允许的表名集合
map[string]bool{"users": true, "products": true}，查c.QueryParam("table")是否在其中 - 排序字段同理：
validSortFields := map[string]bool{"created_at": true, "name": true}，拒绝sort=id; DROP TABLE users-- - 不要用
fmt.Sprintf("ORDER BY %s", sanitize(sort))试图“过滤”，Unicode 控制字符或反斜杠后跟空格仍可能绕过 - 如果业务真要支持任意列排序，前端应只暴露下拉菜单，后端只从预设字段映射取值，不解析原始字符串
容易被忽略的边界点
安全链最弱的一环往往不是主查询，而是日志、调试输出、错误构造或子查询拼接。
- 别在
log.Printf("failed query for user %s", username)里直接打用户输入——可能泄露敏感值到日志系统 - 用
fmt.Sprintf构造子查询（如"(SELECT COUNT(*) FROM "+table+")"）和主 SQL 拼一起，等于绕过所有参数化努力 - 第三方包如
sqlx的NamedQuery仍依赖你写对占位符，Rebind()不解决逻辑漏洞 - 测试时用
username=admin' --和q=%'; DROP TABLE--实打实跑一遍，比看文档更管用
