WordPress 默认会拦截并重写包含特定查询参数（尤其是保留字）的 URL，导致自定义 $_GET 参数被误判为非法路由而返回 404；根本原因常是参数名与 WordPress 内置查询变量、主题或插件已注册的查询变量冲突。
wordpress 默认会拦截并重写包含特定查询参数（尤其是保留字）的 url，导致自定义 `$_get` 参数被误判为非法路由而返回 404；根本原因常是参数名与 wordpress 内置查询变量、主题或插件已注册的查询变量冲突。
在将原生 PHP 程序迁入 WordPress 时，直接使用标准 URL 查询字符串（如 /program/?artist=1&genre=rock）却遭遇 404，通常并非服务器配置或 .htaccess 问题，而是 WordPress 的查询变量（query vars）机制在起作用。
WordPress 在初始化过程中会解析 URL，并将查询字符串中的键名与内部白名单（$wp->public_query_vars 和 $wp->private_query_vars）比对。若参数名（如 artist）恰好与 WordPress 核心、当前主题或激活插件中已注册的查询变量同名，WordPress 会尝试将其作为合法查询条件处理；若该变量未被正确映射到实际逻辑（例如没有对应的 pre_get_posts 钩子或模板逻辑），最终路由匹配失败，便返回 404 —— 即使页面本身存在。
你观察到添加 $ 前缀（如 ?$artist=1）后页面“能识别”，实则是绕过了 WordPress 的查询变量解析：因为 $ 不符合 PHP 变量命名规范，WordPress 的 parse_request 流程会跳过该键，使其不进入 query var 白名单校验，从而让 $_GET['$artist'] 可被原始脚本读取（但语义已破坏，且不可靠）。
✅ 正确解决方式不是加符号“欺骗”，而是：
避免使用保留关键字：WordPress 官方保留的查询变量包括
author,post_type,category_name,tag,s（搜索）,p（文章 ID）等；此外，主题或插件可能额外注册如artist,album,venue等。务必检查 WordPress Query Var 文档 并审查主题functions.php及插件中add_rewrite_rule()或query_vars过滤器。-
安全注册自定义参数（推荐）：若需长期使用某参数（如
producer），应在主题或插件中显式声明：// 在 functions.php 或插件中 add_filter('query_vars', function($vars) { $vars[] = 'producer'; // 允许 $_GET['producer'] 被识别 $vars[] = 'genre'; return $vars; });随后，在模板或自定义页面中即可安全使用：
$producer_id = get_query_var('producer', 0); // 安全获取，自动转义 if ($producer_id) { // 执行 SQL 查询或 WP_Query } -
验证参数名冲突的快捷方法：
// 临时加入 functions.php 调试 add_action('wp', function() { error_log('All registered query vars: ' . print_r($GLOBALS['wp']->public_query_vars, true)); });查看 PHP 错误日志，搜索你的参数名（如
artist）是否已存在。
⚠️ 注意事项：
- 不要依赖
$_GET直接读取未注册的参数，这在启用了「固定链接」（Permalink）的站点上极易失效； - 数据库字段名（如
artist）可保留，但 URL 参数名必须区分（如改用producer_id）； - 若涉及大量参数（如题中 28 个），建议改用 POST 请求或 JSON API 接口，避免 URL 长度限制与 SEO 干扰。
总结：WordPress 的 404 并非拒绝 $_GET，而是严格保护其查询系统——所有公开 URL 参数都需“报备”。一次参数名调整（artist → producer）之所以生效，正是因为避开了隐式冲突。专业迁移的关键，是尊重 WordPress 的请求生命周期，而非绕过它。
