双引号包裹变量是唯一能同时处理空格、单引号、反斜杠和换行的可靠方式；裸写 $where_condition 会因 shell 以空白字符分词导致参数断裂，如 where a = 'O'Connor' 被切为 where、a、=, 'O'Connor' 四段。
直接用双引号包裹变量并传参，是唯一能同时处理空格、单引号、反斜杠和换行的可靠方式；其他方法（如不加引号、用$IFS、转义空格）在SQL场景下极易断裂或被截断。
为什么裸写 $where_condition 会丢参数
Shell 默认以空白字符（空格、制表符、换行）切分位置参数。当你写 test_param a $where_condition，而 $where_condition 展开为 where a = 'O'Connor'，Shell 会在第一个空格处就切开，把 where 当作 $2，a 当作 $3，后面全乱了。
- 单引号、双引号、括号、分号这些 SQL 常见字符，在未加引号的变量展开中不会被识别为语法单元，只会被当作文本切分依据
-
eval虽然能“修复”展开，但引入命令注入风险，绝对不要用于用户可控输入 - 用
\手动转义空格（如where\ a\ =\ 'O...'）只对当前 shell 有效，一旦进函数再赋值给新变量，转义符本身可能被吃掉或误解析
必须用双引号包裹变量展开
这是最简、最稳、最通用的做法。双引号允许变量展开、命令替换，同时保留内部空格和大多数特殊字符的字面意义。
Linux Security Scanner
下载
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
- 写法：用
"$where_condition"，不是$where_condition，也不是'$where_condition'（单引号会禁止变量展开） - 如果 SQL 里含双引号（比如 JSON 字段），没问题——双引号只作用于 shell 解析层，不影响 SQL 语句本身
- 如果 SQL 里含
$（比如 PostgreSQL 的$$字符串定界符），需注意：双引号内$仍会触发变量/命令替换，此时应改用"${where_condition}"避免歧义，或提前用单引号定义原始字符串
避免在函数里重新解析 SQL 字符串
别在函数内部对参数做二次 eval、set -- 或 read 拆分——这等于把问题又抛回 shell 解析器，重复踩坑。
- 函数体里直接用
$2即可，它已经是完整字符串，不需要echo $2 | xargs -I{} psql -c "{}"这类多余操作 - 若需拼接，用
"SELECT * FROM t WHERE $2"这种字符串连接，仍需确保整个结果被双引号包住 - 真正要执行时，交给
psql -c "$sql"或mysql -e "$sql"——这些客户端工具自己会按完整字符串处理，不依赖 shell 分词
复杂 SQL 场景下的额外约束
当 SQL 含换行、多级嵌套引号、或需兼容不同数据库时，仅靠引号还不够，得配合调用方式控制上下文。
- 换行安全：双引号天然保留换行，
psql -c "$sql"完全支持多行 SQL；但mysql -e "$sql"在某些旧版 mysql 客户端中会截断换行，此时应改用mysql here-document 方式 - PostgreSQL
$$定界符：若 SQL 内含$$，且你用psql -c "$sql"，没问题；但若你在脚本里用echo "$sql" | psql，要注意管道不会改变字符串内容，依然安全 - 绝对不要混用：比如
psql -c "SELECT * FROM t WHERE $(echo "$where")"——命令替换发生在双引号内，但$(...)的输出仍会被 shell 分词，等同裸写
最易被忽略的一点：SQL 字符串一旦生成，就该当作不可分割的原子值对待。任何试图“拆开再拼”的操作（包括在函数里用 for word in $2、用 awk '{print $1}' 提取字段、甚至用 printf %q 二次转义）都会破坏原始语义——这不是 shell 的限制，而是 SQL 作为结构化语言与 shell 文本协议之间的根本错位。
