QSA标志的核心目的是合并原始查询参数与重写目标中的查询字符串，而非简单追加；其机制是后者优先覆盖同名参数，需确保RewriteEngine开启、AllowOverride允许且规则上下文正确。

在虚拟主机中使用 mod_rewrite 的 [qsa]（query string append）标志，核心目的是让重写后的 url 自动合并原始请求中的查询参数，避免手动拼接或意外丢失。它不是“开启即生效”的魔法开关，而是在规则匹配后、重定向或内部重写过程中，控制查询字符串如何参与最终 url 构建的关键机制。

QSA 的作用机制：不是追加，而是“合并”

[QSA] 并非简单地把旧参数加到新 URL 末尾。它的实际行为是：将原始请求的查询字符串（?key=value&...）与重写目标中已存在的查询部分（如有）合并，且后者优先级更高（同名参数会被覆盖）。例如：

• 原始请求：/article/123?ref=home&utm_source=mail
• 规则：RewriteRule ^article/(\d+)$ /view.php?id=$1 [QSA]
• 结果：/view.php?id=123&ref=home&utm_source=mail

若目标中已有同名参数（如 /view.php?id=$1&ref=hardcoded），则 ref=hardcoded 会覆盖原始的 ref=home —— 这是 QSA 合并逻辑的关键细节，常被忽略。

虚拟主机中启用 QSA 的前提条件

多数共享虚拟主机默认启用 mod_rewrite，但需确认以下三点才能让 [QSA] 正常工作：

• .htaccess 文件被允许解析：检查主机是否支持 AllowOverride All（通常由主机商配置，用户无法修改；若报 500 错误，可能是 AllowOverride 被设为 None）
• RewriteEngine 已开启：在 .htaccess 开头必须有 RewriteEngine On
• 规则位于正确的上下文：虚拟主机中一般用 .htaccess，此时 RewriteBase 建议显式声明（如 RewriteBase /），否则路径匹配易出错

常见误用场景与安全提醒

QSA 本身不校验参数内容，直接透传可能带来风险：

• 不要在重写到外部域名时盲目用 QSA：例如 RewriteRule ^old/(.*)$ https://new.com/$1 [QSA,R=301] 会把原始参数完整带到新站，若含敏感信息（如 ?token=abc）将暴露
• 避免与 [L] 混用导致逻辑中断：[QSA] 必须和重写目标共存于同一规则行，若写成两行（如先 RewriteRule 再单独加 [QSA]）无效
• 中文或特殊字符参数需确保编码一致：原始请求若为 UTF-8 编码，重写后 PHP 接收时也应以 UTF-8 处理，否则出现乱码——QSA 不负责解码，只传递原始字节流

调试 QSA 是否生效的实用方法

在目标脚本（如 view.php）开头加入诊断代码：

echo "REQUEST_URI: " . $_SERVER['REQUEST_URI'] . "\n";
echo "QUERY_STRING: " . $_SERVER['QUERY_STRING'] . "\n";
print_r($_GET);

对比访问 /article/123?x=1&y=2 和重写后实际收到的参数，即可确认 QSA 是否按预期合并。若 $_GET 中缺失参数，优先检查规则语法、RewriteBase 设置及服务器是否屏蔽了 .htaccess。