SQLAlchemy 已设 hide_parameters，默认值仍出现在日志里

engine 已设置 hide_parameters=True，日志里却仍出现某个列默认值的绑定内容，而且前缀是 [raw sql]。如果这段 SQL 来自默认值表达式或序列预执行，需要检查它是否经过了独立的游标执行路径。

SQLAlchemy 2.1.6 的 Connection._cursor_execute() 在记录这类参数时，没有使用常规执行路径中的 hide_parameters 判断。2.0 系列也有对应报告。因此，普通 SELECT 的参数确实被隐藏，并不能证明默认值预执行同样安全。

先减少输出，再定位路径

有敏感值时，先按应用既有日志策略停止相关 SQL 参数输出。通常要同时检查 engine 的 echo 配置和实际 sqlalchemy.engine 子记录器等级；只改 logging.basicConfig()，可能没有改变已经配置好的子记录器或处理器。

echo=False 不代表其他地方开启的 SQLAlchemy INFO 日志也一定关闭。核对应用创建 engine 的全部入口、logging_name 和日志集中采集规则，确认受影响日志确实停止进入控制台及日志平台。不要为了验证而把真实密码、令牌或业务数据再写一次日志。

随后在隔离配置中使用无敏感信息的哨兵默认值，区分普通语句执行与列默认值预执行。目标日志形式可以按下面的样式识别，示例中的值没有业务含义：

SELECT ? AS anon_1
[raw sql] ('audit-sentinel',)

此问题需要参数日志实际启用，并经过相关执行路径才会显现，不是每条 SQL 都会泄露。hide_parameters 本身也不是数据脱敏器：若应用把秘密直接拼进 SQL 文本，即便参数部分隐藏，文本仍可能被记录。

不要用关闭绑定参数来绕过日志问题

保持正常参数绑定。改成字符串拼接、删除默认值的业务含义，或把日志移到另一个仍保存参数的通道，都没有解决暴露范围。是否改用应用侧默认值，应单独审校生成时机和数据库语义，不能当成没有影响的日志开关。

更换 SQLAlchemy 版本后，要用同一默认值预执行路径检查参数是否仍被记录；普通 SELECT 已隐藏参数，不能替代这项检查。在确认日志行为前，保留上述输出限制。

历史日志已经输出的内容不会因升级消失。按已有访问控制和保留流程确认哪些日志副本可能含有敏感值；是否需要轮换相关凭据，取决于实际输出、访问范围和业务响应要求。不要无依据删除整套日志，丢掉其他故障的审计证据。

验收应覆盖普通 SQL、SQL 表达式默认值及应用实际使用的序列或批量写入入口。只使用无敏感值的样例，确认日志策略生效且插入结果仍符合原业务契约；回退依赖时也要保留这项日志限制。