两个模块都给同一方法加了 plugin，日志顺序却和 sortOrder 的直觉不一样。尤其出现 around 后，入口和返回阶段是嵌套的，只看一串日志很容易误判。
先画调用栈，不要只背排序规则
before 与 around 的进入顺序受配置排序影响，after 发生在返回过程。around 调用 $proceed() 前后的代码会包住后续链，所以日志常呈现：
before A
around A enter
before B
original method
after B
around A leave
after A调试时为每个 plugin 打印类名、阶段和请求 ID，比只记录 plugin called 更容易确认链条。
around 不调用 proceed 会截断后续
第三方模块为了返回缓存结果，可能在条件分支直接 return。此时后面的 plugin 和原方法都不会执行。检查每条 return 路径，并确认参数、返回类型与目标方法兼容。
最终配置来自多个 di.xml 合并
同名 plugin 可以被其他模块禁用或覆盖，area 配置也会改变结果。检查模块加载顺序和生成的 interceptor。目标方法若是 final、static、构造函数或其他不可拦截范围，也不会按预期工作。
只需改参数时用 before，只改结果时用 after，确实需要包围调用再用 around。修复后用集成测试断言最终输入输出，不要把脆弱的完整日志顺序当成唯一业务契约。
