CodeIgniter路由配置通过application/config/routes.php文件定义URL与控制器方法的映射，支持占位符如(:num)、(:any)及正则表达式实现动态路由，提升URL可读性、SEO友好性和安全性；利用$route['default_controller']设置默认首页，$route['404_override']自定义错误页面，并遵循“具体到通用”的规则顺序避免匹配冲突，同时可通过admin/(:any)等模式模拟路由组管理模块化结构，适用于前后台分离与RESTful API设计，是优化应用架构与用户体验的关键手段。
CodeIgniter的路由配置，核心在于application/config/routes.php文件，通过定义URL模式与控制器方法的映射关系，让你的应用URL更优雅、更易读，也更安全。它不仅仅是简单的重定向，更是一种对应用结构和用户体验的深层思考。
在CodeIgniter中，路由配置主要集中在application/config/routes.php这个文件中。打开它，你会看到一个$route数组，所有的规则都将在这个数组中定义。最基础的规则是$route['uri'] = 'controller/method';。例如，如果你想让http://your-domain.com/products访问Products控制器的index方法，你可以这样写：$route['products'] = 'products';（CodeIgniter默认会找index方法）。如果想访问detail方法，且带参数，比如http://your-domain.com/product/123，你就需要用到占位符：$route['product/(:num)'] = 'products/detail/$1';。这里的(:num)匹配数字，$1则代表捕获到的第一个参数。CI提供了(:any)匹配任何字符，(:num)匹配数字，(:alpha)匹配字母，(:alphanum)匹配字母和数字等多种占位符，足以应对大多数场景。
为什么需要自定义CodeIgniter路由，它解决了哪些痛点？
说实话，刚接触CodeIgniter时，我一度觉得默认的controller/method/param结构也挺好用，直接明了。比如site.com/users/show_profile/123，虽然有点长，但至少能一眼看出在做什么。但随着项目复杂度的提升，特别是考虑到用户体验和搜索引擎优化（SEO），默认路由的局限性就显现出来了。
首先，裸露的控制器名和方法名有时并不“友好”。想象一下，如果你的方法名是get_user_details_by_id，那么URL会变得非常冗长。将其美化成site.com/profile/123是不是更简洁、更具语义化？这不仅让用户更容易记住和分享URL，也让你的网站在搜索引擎中看起来更专业。
其次，自定义路由能在一定程度上提升安全性。隐藏真实的控制器和方法名，虽然不是什么铜墙铁壁，但至少能增加攻击者猜测你的后端结构和尝试非法访问的难度。它是一种“不暴露太多信息”的策略。
更重要的是，路由提供了一种解耦的能力。即使你因为重构而更改了控制器或方法名，只要路由规则不变，外部访问接口就依然稳定。这在大型团队协作或长期维护的项目中，简直是救命稻草。我记得有一次，我们团队需要将一个老旧模块的URL结构彻底翻新，如果不是有路由层做缓冲，那改动量简直无法想象，可能需要修改无数前端链接和API调用方。
CodeIgniter路由配置中的常见占位符和优先级问题
在CodeIgniter的路由配置中，占位符是实现动态URL的关键。除了前面提到的(:any)、(:num)、(:alpha)、(:alphanum)，CI还支持更强大的正则表达式。比如，如果你想匹配一个包含短横线的产品SKU，$route['product/([a-zA-Z0-9-]+)'] = 'products/view/$1'; 这样的写法就能派上用场，这里的([a-zA-Z0-9-]+)就是一个自定义的正则表达式捕获组。
但这里有个坑，就是路由的优先级。CI会按照routes.php文件中定义的顺序，从上到下依次匹配用户请求的URL。这意味着，如果你把一个更通用的规则放在了一个更具体的规则前面，那么那个具体的规则可能永远不会被匹配到。举个例子：
// 错误的优先级示例 $route['(:any)'] = 'errors/page_missing'; // 过于通用，放在前面会捕获所有请求 $route['products/(:num)'] = 'products/detail/$1'; // 这条规则可能永远不会被匹配到
在这种情况下，任何URL都会先匹配到(:any)，然后直接跳转到错误页面，products/detail的规则就失效了。所以，一个黄金法则就是：把最具体的规则放在最前面，最通用的规则放在最后面。
正确的做法应该是这样：
// 正确的优先级示例 $route['products/latest'] = 'products/latest_products'; // 最具体的规则 $route['products/(:num)'] = 'products/detail/$1'; // 其次具体的规则 $route['blog/(:any)'] = 'blog/view/$1'; // 相对通用的博客文章 $route['(:any)'] = 'errors/page_missing'; // 最通用的404捕获，放在最后
我曾经就因为这个优先级问题，排查了一个半天的bug，最后才发现是几行路由规则的顺序搞错了，那感觉真是又好气又好笑，但也是一次深刻的教训。
如何处理CodeIgniter中的默认路由、404错误以及路由组？
除了自定义路由，routes.php文件里还有几个非常重要的默认配置。$route['default_controller'] = 'Welcome'; 这行定义了当用户只访问域名时，系统会加载哪个控制器。通常，我们会把它改成自己的首页控制器，比如'Home'，这样用户访问http://your-domain.com时就能直接看到你精心设计的首页。
另一个是$route['404_override'] = '';。当没有任何路由规则匹配到用户请求的URL时，CI会默认显示一个标准的404页面。但通过设置这个404_override，你可以指定一个自定义的控制器方法来处理所有未找到的页面，比如$route['404_override'] = 'errors/page_missing';。这样，你就可以提供更友好、更符合品牌形象的错误提示页面，甚至可以记录下这些无效的访问请求。
对于更复杂的应用，特别是当你有多个模块或API时，CodeIgniter虽然在较老的CI3版本中没有原生提供像CI4那样完善的“路由组（Route Groups）”语法，但我们依然可以通过一些技巧实现类似的功能，比如利用通配符和目录结构。
例如，如果你有一个后台管理系统，所有URL都以admin/开头，你可以这样定义：
$route['admin/(:any)'] = 'admin/$1';
这会将所有形如admin/users/list的请求映射到application/controllers/admin/Users.php控制器的list方法。这种方式虽然不是严格意义上的“路由组”语法，但它实现了类似的功能，使得管理后台的路由配置更加集中和易于维护。
再比如，处理RESTful API时，CI3通常需要手动定义不同HTTP方法的路由。虽然CI4引入了更便捷的资源路由，但在CI3中，我们通常会这样操作：
// 获取所有用户 (GET /api/users) $route['api/users'] = 'api/users_controller/index'; // 获取单个用户 (GET /api/users/123) $route['api/users/(:num)'] = 'api/users_controller/show/$1'; // 创建新用户 (POST /api/users) // 注意：CI3默认只处理GET请求到URI，POST等需要额外处理或在控制器中判断请求方法 // 更常见的是，通过路由映射到不同的方法，或者在单个方法中处理 $route['api/users/add'] = 'api/users_controller/create'; // 假设POST请求到这个URI // 更新用户 (PUT /api/users/123) $route['api/users/update/(:num)'] = 'api/users_controller/update/$1'; // 删除用户 (DELETE /api/users/123) $route['api/users/delete/(:num)'] = 'api/users_controller/delete/$1';
这种手动定义虽然在数量多时会显得有点繁琐，但胜在灵活，可以精确控制每个API端点的行为。
总结来说，CodeIgniter的路由配置远不止表面上那么简单，它是一门艺术，也是一门工程。理解并善用它，能让你的应用URL结构更清晰、更强大，也更符合现代Web开发的最佳实践。
