CodeIgniter 3.1.13需手动在routes.php中添加日志：先定义WRITEPATH，再用file_put_contents记录URI和匹配过程，配合ROUTE_DEBUG开关控制，避免生产环境启用。
CodeIgniter 3.1.13 本身不提供内置的 URL 路由匹配日志功能，必须手动在 routes.php 中插入调试逻辑，否则你看不到任何路由匹配过程。
怎么在 routes.php 里加路由匹配日志
CI3 的路由解析发生在框架加载早期，routes.php 是唯一能“拦截”原始 URI 并观察匹配行为的地方。你不能依赖日志类（$this->log）——此时控制器和日志系统都还没初始化。
- 直接在
application/config/routes.php开头加入写文件逻辑，例如：file_put_contents( WRITEPATH . 'logs/route_debug.log', date('Y-m-d H:i:s') . " | URI: " . $_SERVER['REQUEST_URI'] . "\n", FILE_APPEND ); - 每条
$route[...]规则前加一行日志，用strpos()或preg_match()模拟匹配判断，再记录是否命中：if (preg_match('#^/api/v1/(\d+)#', $_SERVER['REQUEST_URI'], $m)) { file_put_contents(WRITEPATH . 'logs/route_debug.log', "MATCHED api/v1/(:num) → api/v1/show/$1\n", FILE_APPEND); $route['api/v1/(:num)'] = 'api/v1/show/$1'; } - 注意
WRITEPATH在 CI3.1.13 中默认未定义，需手动补全：defined('WRITEPATH') OR define('WRITEPATH', FCPATH . 'writable/');（确保writable/logs/目录存在且可写）
为什么不能用 $this->router->class 或 $this->uri->segment() 做日志
这些属性只在控制器实例化后才可用，而路由匹配早在控制器加载之前就完成了。你在控制器里打印 $this->router->method 看到的是“最终结果”，不是“匹配过程”。比如 /news/123 匹配了 $route['news/(:num)'] = 'articles/read/'，但控制器里只能看到 articles 和 read，无法回溯原始规则是否被跳过、被覆盖或因顺序问题失效。
在SEO发布前，从路由清单生成XML网站地图和robots.txt
下载
当代理已经知道网站路由或内容URL，并且在启动前需要有效的sitemap XML、sitemap索引或robots.txt引用时，请使用sitemap。这是一个发布构件技能，而不是爬虫或SEO平台。
- 常见错误：把日志写在控制器构造函数里，误以为能捕获路由决策 —— 实际上这时路由早已执行完毕
- 真实场景：两条规则
$route['user/(:any)']和$route['user/login']顺序颠倒，会导致/user/login被前一条通配规则吃掉，但控制器里完全看不出原因 - CI3 不校验
$route数组键名合法性，拼错路径如$route['admin/']（末尾斜杠）可能静默失效，只有靠日志才能发现没进这条分支
如何避免日志干扰生产环境
硬编码日志会拖慢每次请求，且暴露路径细节。上线前必须移除或加开关控制。
- 用常量开关，例如定义
defined('ROUTE_DEBUG') OR define('ROUTE_DEBUG', ENVIRONMENT === 'development');，所有日志包裹在if (ROUTE_DEBUG) { ... }中 - 不要用
error_log()，它可能写入 Web 服务器错误日志（权限受限或格式混乱），坚持用file_put_contents()写入writable/logs/ - 别记录敏感内容：过滤掉
$_SERVER['QUERY_STRING']或含 token/password 的 URI 片段，防止日志泄露凭证
真正难的不是加几行日志，而是理解 CI3 路由是纯数组驱动 + 顺序匹配，没有中间件钩子、没有事件系统。所有“为什么没走这条路”的问题，都得回到 routes.php 逐行模拟匹配逻辑——日志只是帮你把脑内推演落到磁盘上而已。
