必须将「当前时间」抽象为可注入的依赖，而非直接调用 time() 或 date()；通过接口封装（如 TimeProviderInterface）和依赖注入实现运行时与测试时的不同行为，确保单元测试可控、隔离且可重复。
直接用 time() 或 date() 获取当前时间的代码，单元测试时会不可控——每次运行结果都可能不同，时间跳变还会导致断言失败。必须把「当前时间」抽象出来并可被替换。
为什么不能在测试里直接改系统时间
强行调用 date_default_timezone_set() 或修改服务器时钟不仅不现实，还会污染全局状态、影响并发测试，且 PHP 本身不提供安全的系统时间劫持机制。真正可行的是让业务逻辑不直接依赖 time()，而是通过一个可注入的时间提供者。
用依赖注入 + 接口封装 time()
定义一个简单接口，比如 TimeProviderInterface，只暴露一个 now() 方法返回整型时间戳；实际运行时用默认实现调用 time()；测试时传入一个返回固定值的 Mock 实现。
常见做法：
立即学习“PHP免费学习笔记（深入）”；
- 在类构造函数中接收
TimeProviderInterface $timeProvider，而非在方法内硬编码time() - 若使用 PHPUnit，可用
$this->createMock(TimeProviderInterface::class)，然后->method('now')->willReturn(1717027200) - 避免用
time()的别名（如$_SERVER['REQUEST_TIME']）做兜底——它同样不可控，且在 CLI 环境下可能为空
静态调用场景：如何 Mock date() / time() 这类全局函数
无法修改源码时（如遗留项目），可用 php-mock-phpunit 扩展拦截函数调用。它通过 define() 和 eval() 在测试作用域内重写函数行为。
示例（需先 composer require --dev php-mock/php-mock-phpunit）：
use phpmock\phpunit\PHPMock;
class MyTest extends \PHPUnit\Framework\TestCase
{
use PHPMock;
public function testSomethingWithFixedTime()
{
$timeFunction = $this->getFunctionMock("MyNamespace", "time");
$timeFunction->expects($this->once())->willReturn(1717027200);
$result = someFunctionThatCallsTime();
$this->assertEquals('2024-05-31', date('Y-m-d', $result));
}
}
注意：
- 必须指定函数所在命名空间（第二个参数），否则无法精准拦截
- 仅对未声明为
final的类中的函数调用有效；若目标代码用了\time()全局调用，命名空间应传空字符串"" - 该方案性能略低，且与某些 OPcache 配置或 HHVM 不兼容，生产环境勿用
Carbon 实例的测试陷阱
很多人以为 Carbon::now() 可以直接 Mock，但 Carbon 内部仍调用 time() 和 microtime()。正确方式是：
- 调用
Carbon::setTestNow(Carbon::create(2024, 5, 31))启用测试模式（注意：这是静态全局开关） - 每个测试后务必调用
Carbon::setTestNow()清空（传 null 或无参），否则会影响后续测试 - 不要在
setUp()里统一设，而应在每个用到时间的测试方法内显式设置+清理，避免状态泄漏
更稳妥的做法仍是把 Carbon 实例作为依赖传入，而不是在业务逻辑里直接调用静态方法。
时间相关逻辑的可测性，本质上取决于你是否把它当成一个外部依赖来对待——哪怕它看起来“免费又稳定”，一旦固化在代码深处，就会成为测试时最顽固的变量。
