我想我经过大量命令行调试(使用phpstorm)后找到了答案:

I think I found the answer after a lot of command line debugging (using phpstorm):

像这样声明控制器中的POST寄存器路由处理功能:

The POST register route handling function in the controller was declared like this:

public function postRegister(RegistrationRequest $request)
{

...要求通过依赖项注入传递Request的实例.该请求包含一些验证代码，如果由于某种原因验证代码无法完成(例如引发异常)，则控制器函数将永远不会被调用-因为构建请求失败.

... requiring an instance of Request to be passed in via dependency injection. That request contained some validation code and if for some reason the validation code could not complete (e.g. throws an exception) then the controller function never gets called -- because building the request fails.

在浏览器范围内，这将引发500错误，但在代码接收范围内，异常被捕获的方式有所不同，并且它返回到/的重定向(不包含任何数据).这一切都发生在控制器功能之外而不是内部，因此控制器功能中的Log语句永远不会运行，因为永远不会调用该函数.代码接收中的异常处理程序是一个通用陷阱.

This, in browser-land, throws a 500 error but in codeception land the exception is trapped differently and it returns a redirect to / with no data. This all happens outside of the controller function rather than inside it, so that the Log statement in the controller function never runs because the function never gets called. The exception handler in codeception is a generic trap.

隐含的建议是，在控制器中进行依赖项注入可能不是一个好主意.或者，也许通用异常处理程序是个坏主意.

The implicit suggestion is that maybe dependency injections in controllers are a bad idea. Or, maybe, that generic exception handlers are a bad idea.