现代PHP项目中直接拼接$_GET参数URL不安全不友好，因其易被恶意构造、不利SEO、暴露后端结构且路由变更维护困难；应通过路由系统反向生成URL，统一管理并适配环境。
为什么直接拼接 $_GET 参数的 URL 在现代 PHP 项目里越来越不安全也不友好
因为裸露的 ?id=123&category=news 容易被恶意构造、不利于 SEO、对用户不直观，且暴露了后端结构。更关键的是，一旦路由逻辑分散在各处（比如用 header("Location: ...") 手动跳转），后期改 URL 规则时得全局搜索替换，极易出错。
真正可靠的动态 URL 生成，必须和路由系统绑定——不是“拼字符串”，而是“查路由名反向生成 URL”。
- 用框架（如 Laravel 的
route()、Symfony 的url()）是首选：自动适配当前环境（HTTP/HTTPS、子目录部署）、支持命名路由、参数自动编码 - 纯 PHP 手写时，别硬拼
"article.php?id=" . $id，应封装一个generate_url($name, $params)函数，集中管理路径模板 - 所有前端链接（包括表单
action、AJAX 地址）都走这个生成器，避免散落的字符串字面量
Apache + .htaccess 伪静态重写常见失效原因
写完 RewriteRule ^article/([0-9]+)$ article.php?id= [L] 却 404？大概率不是规则错，而是底层没开权限或配置未生效。
-
AllowOverride All必须在虚拟主机或目录配置中显式启用，否则.htaccess被完全忽略 - 确保
mod_rewrite已启用：a2enmod rewrite（Debian/Ubuntu）或检查httpd.conf中LoadModule rewrite_module是否取消注释 - 重写目标文件（如
article.php）必须真实存在且可执行；若用FallbackResource模式，则需 PHP 入口统一处理，此时.htaccess只做“兜底转发”，不再按路径匹配具体文件 - 本地测试用 XAMPP/MAMP 时，注意其默认可能禁用
.htaccess，需手动开启
PHP 路由入口统一处理时，如何安全解析原始 URL
当所有请求都指向 index.php（即前端控制器模式），$_SERVER["REQUEST_URI"] 是唯一可靠来源，但直接用它有陷阱。
立即学习“PHP免费学习笔记（深入）”；
- 务必用
parse_url($_SERVER["REQUEST_URI"], PHP_URL_PATH)提取路径部分，去掉查询参数和锚点，防止注入 - 手动
trim($path, "/")去首尾斜杠，避免空段导致匹配失败 - 不要信任
$_SERVER["PATH_INFO"]—— 它在 CGI/FastCGI 下常为空或不可靠，Nginx 更是默认不设置 - 如果 URL 含中文或特殊符号，
rawurldecode()解码后再匹配，否则路由规则会失配
Nginx 伪静态配置与 Apache 的关键差异点
Nginx 没有 .htaccess，所有重写必须写在 server 或 location 块里，且语法和行为不同。
- Apache 的
[L]对应 Nginx 的last（内部重定向）或break（停止匹配），用错会导致循环或 404 - Nginx 默认不传递查询参数，要显式加
?$args：rewrite ^/article/(\d+)$ /article.php?id=$1?$args last; - 更推荐用
try_files实现“先找静态文件，不存在则交由 PHP 处理”：try_files $uri $uri/ /index.php?$query_string;，比 rewrite 更高效也更安全 - PHP-FPM 的
fastcgi_param SCRIPT_FILENAME必须设为$document_root$fastcgi_script_name，否则 Nginx 可能传错脚本路径
