Zhu Ming

我也遇到同样的动态路由失效的问题，同样的无法加载控制器的错误。看[3.2.4的9个commits](https://github.com/top-think/thinkphp/compare/v3.2.5...master)和[3.2.5的3个commits](https://github.com/top-think/thinkphp/compare/3.2.4...master)，完全没有改到路由，但是框架路由的行为发生了变化。原来应用程序的代码可以正常工作，升级到3.2.4之后却不行了。查看了一下2015年10月8日3.2.3发布之后的commits，其实有很多改动，远不止上述的12个commits，路由的部分，比如`Library/Think/Dispatcher.class.php`和`ThinkPHP/Library/Think/Route.class.php`都有比较大的变动。是否有相应的文档，说明这些框架的变化对应用程序有哪些影响，需要相应作出什么样的改动呢？ 谢谢！

@jdkysq @bigiot 经过一番调试，发现对框架做如下改动，可以修复我的问题： [ThinkPHP/Library/Think/Route.class.php第61行](https://github.com/top-think/thinkphp/blob/e9d317d891dbdd2df461e2bce61f334f8dc1eda0/ThinkPHP/Library/Think/Route.class.php#L61)由： ```php if ($matches = self::checkUrlMatch($rule, $args, $regx)) { ``` 改为： ```php $matches = self::checkUrlMatch($rule, $args, $regx); if ($matches !== false) { ``` 道理也很简单，我猜测私有方法`checkUrlMatch()`返回`false`表示动态路由未匹配成功，而在返回值的判断上，误把空数组也当成未匹配成功。 我还要测试一下，看这样是否适用于我所有的近300个动态路由(有web，也有API)。如果的确如此，我会提交一个PR。可能的话，希望大家也可以帮我测试一下，看是否能解决问题，另外是否还有其他问题。 既然3.2官方已经不维护了，所以要靠社区中还在使用该版本的我们自己来承担这个责任了。 谢谢！

之前对路由的修正仍不完整。又经过几天折磨人的调试，终于使我近300个动态路由(有web，也有API)又能够在3.2.5下正常工作了，通过单元测试。下面是我对框架的完整修正(包括之前提到的)，只涉及一个文件`ThinkPHP/Library/Think/Route.class.php`： [ThinkPHP/Library/Think/Route.class.php第61行](https://github.com/top-think/thinkphp/blob/e9d317d891dbdd2df461e2bce61f334f8dc1eda0/ThinkPHP/Library/Think/Route.class.php#L61)由： ```php if ($matches = self::checkUrlMatch($rule, $args, $regx)) { ``` 改为： ```php $matches = self::checkUrlMatch($rule, $args, $regx); if ($matches !== false) { // 严格检查false才表示动态路由未匹配成功 ``` [ThinkPHP/Library/Think/Route.class.php第440行](https://github.com/top-think/thinkphp/blob/e9d317d891dbdd2df461e2bce61f334f8dc1eda0/ThinkPHP/Library/Think/Route.class.php#L440)由： ```php // 如果值在排除的名单里...

@liu21st 我已经提交了PR #535，请检查，如需改进请告知。 另外，建议对框架的修改，必须分外谨慎，因为框架是很多用户开发应用的基础，一旦引入了哪怕很小的错误，也有可能影响很多人。尤其是3.2已经过了维护生命周期，更多的可能是对安全性等不得不做的更新，核心团队对其关注度肯定不如正在开发和使用的5.0等版本，相比而言3.2也缺乏单元测试等比较好的质量验证手段，使得任何改动都更难验证。 谢谢！

又有一些新的对路由的修正，详见PR #535。 关于路由的单元测试，可见示例项目[blackpuppy/thinkblog](https://github.com/blackpuppy/thinkblog)。

@jdkysq > 还发现一个问题，我将路由定义在子模块配置文件，这样就失效了，需要将路由定义到主配置文件 有测试用例吗？有空的时候，我也试一下。我用过不同的模块，但没用过子模块。

@jdkysq 参考3.2的文档[路由定义](https://www.kancloud.cn/manual/thinkphp/1706)： > 启用路由 > > 要使用路由功能，前提是你的URL支持PATH_INFO（或者兼容URL模式也可以，采用普通URL模式的情况下不支持路由功能），并且在应用（或者模块）配置文件中开启路由： 不知道你说的子模块，是3.2支持的功能吗？为什么我在3.2的文档里没有搜到？

@jdkysq 你所谓的”子模块“，从你的代码看，就是模块。比如子目录，强调是目录下的目录，前面才加个”子“，子模块，亦如此。但是从你提供的代码看，`Plugin`模块并不在另一个模块中，叫”子模块“是不妥的。 路由解析，要根据路由规则来确定模块(以及控制器和操作等)，所以无法先加载模块中定义的路由规则，路由规则只能写在公用模块`Common`中。用你的例子来说明，公用模块`Common`的配置肯定要加载，但是在解析路由确定模块之前，并不知道是否需要`Plugin`模块，所以不会加载`Plugin`模块中的配置。因此，在路由解析时，`Plugin`模块中定义的路由规则就不起作用，只有公用模块`Common`中的路由规则才起作用。这是我的理解。 我怀疑，文档中说的，可以在非公共模块的配置文件中用`URL_ROUTER_ON`配置开启路由，或者用`URL_ROUTE_RULES`来定义路由规则，是否真的可行。如果可行，希望作者(@liu21st)能够提供这样的例子。

我只是表达我的看法，谈不上指正，互相交流。 我是从3.2.3开始用的，发现在非公用模块中配置路由规则就不行，所以都放在公用模块的配置中了。从你经历的情况来看，一些修订号的升级都有很大的影响。如果按照[语义化版本](https://semver.org/lang/zh-CN/)来看，次版本号和修订号的变更不应该包含不兼容的变化，只有主版本号的变化才是不兼容的变化。另外，这种路由解析的重大变化，的确是缺乏明确充分的文档说明和升级指导。 我用的情况很有限，做的修复很可能也没有考虑到所有可能的情况，所以希望有更多的用户测试不同的用例。 另外，`URL_ROUTE_RULES`是动态路由，你说的是静态路由`URL_MAP_RULES`吗？

我发现从 `https://packagist.org/packages/topthink/thinkphp` 下载的 `3.2.5` 并不包换我对路由的修正，GitHub上的 `tag v3.2.5` 同样不对。难道不能更新 packagist.org 上已经发布的版本吗？还是要发布一个新的版本，比如 `3.2.6`，才行？ 现在我只能在用 `Composer` 安装时，使用 `GitHub` 上的 `master` 分支，需要在 `composer.json`中增加下面这段: ``` ... "repositories": [ { "type": "package", "package": { "name": "topthink/thinkphp",...