WordPress 默认会拦截并重写包含特定参数名的 URL，若 $_GET 参数名与 WordPress 内置查询变量（如 artist）冲突，会导致路由失败、页面返回 404，而非正常执行模板逻辑。
wordpress 默认会拦截并重写包含特定参数名的 url，若 $_get 参数名与 wordpress 内建查询变量（如 `artist`）冲突，会导致路由失败、页面返回 404，而非正常执行模板逻辑。
在将原生 PHP 程序迁移至 WordPress 时，常见误区是直接沿用传统 ?key=value 形式的 URL 参数传递方式，却未意识到 WordPress 的查询变量（Query Variables）机制已预注册大量保留关键字——例如 artist、author、name、page、category_name 等。当 URL 中出现这些名称作为 $_GET 参数时，WordPress 的主查询（WP_Query）会尝试将其解析为内部路由或存档条件，一旦匹配失败（如无对应作者或分类），便直接触发 404，甚至尚未进入主题模板或自定义页面逻辑。
你观察到的现象——/home/program/?artist=1&year=2023 返回 404，而改为 /home/program/?$artist=1&year=2023 后页面可加载（但 $_GET['artist'] 取不到值）——正印证了这一点：添加 $ 后，URL 参数名变为 $artist，不再匹配 WordPress 保留字表，因此绕过重写规则，页面得以加载；但由于 PHP 不支持 $ 开头的合法数组键名，$_GET['$artist'] 虽存在，但原始逻辑中 $_GET['artist'] 为空，导致功能异常。
✅ 正确解决方案如下：
-
避免使用 WordPress 保留查询变量名
官方保留变量列表见 WordPress Query Var Documentation。常见冲突词包括：-
artist,author,name,page,year,monthnum,day,post_type,s（搜索）等。
建议统一加前缀，如my_artist,app_year,form_id。
-
-
注册自定义查询变量（推荐）
在主题functions.php或插件中添加：// 注册安全的自定义参数名 function my_register_query_vars($vars) { $vars[] = 'my_artist'; // ✅ 显式声明，允许被识别 $vars[] = 'my_year'; $vars[] = 'my_filter'; return $vars; } add_filter('query_vars', 'my_register_query_vars'); -
在页面模板中安全获取参数
使用get_query_var()（经 WordPress 过滤）或filter_input()（更严格）：// 推荐：利用 WordPress 已注册的变量 $artist = get_query_var('my_artist', ''); // 或更健壮的原生方式（需确保已注册） $year = filter_input(INPUT_GET, 'my_year', FILTER_SANITIZE_NUMBER_INT);
⚠️ 注意事项：
- 不要依赖
$_GET直接读取——WordPress 可能已通过add_rewrite_rule()或parse_request钩子修改请求； - URL 中空格（如
?parameter1=1 & paraemeter2 =2）会导致解析失败，务必确保 URL 编码规范（无空格、键名小写一致）； - 若涉及 28 个参数，建议改用
POST+ AJAX 或封装为 JSON 字符串传递，提升可维护性与安全性； - 调试时启用
WP_DEBUG_LOG并检查wp-content/debug.log，可捕获重写/查询阶段错误。
总结：WordPress 的 404 并非“不识别代码”，而是其路由层主动拒绝了与核心功能语义冲突的参数名。解决的关键在于尊重其查询变量生命周期——不硬撞保留字，而通过注册+过滤实现可控扩展。
