PHP默认时区为UTC，导致date()等函数比北京时间少8小时；需在脚本开头调用date_default_timezone_set('Asia/Shanghai')；strtotime()依赖当前时间基准，应传入明确的$base_time避免错位。
时间戳转本地时间总差8小时？检查 date_default_timezone_set
PHP 默认时区是 UTC，不是你所在服务器或浏览器的本地时区。如果没显式设置，date()、strtotime() 等函数输出的时间会按 UTC 解析，导致显示比北京时间少 8 小时。
常见错误现象：date('Y-m-d H:i:s') 返回 2024-05-20 08:30:00，但你期望的是 16:30:00。
- 在脚本最开头（或框架入口文件）加一句：
date_default_timezone_set('Asia/Shanghai'); - 不要用
'PRC'或'Etc/GMT-8'—— 前者已被弃用，后者反直觉（GMT-8 实际表示 UTC+8 的反向命名，PHP 中它其实是 UTC+8，但语义混乱，易出错） - 可通过
date_default_timezone_get()检查当前生效时区，别只信 php.ini 里的配置 —— 运行时调用可能已覆盖
strtotime() 解析 '今天' '昨天' 结果不准？注意上下文日期基准
strtotime() 是相对解析函数，它依赖“当前时间”作为参考点。如果你在凌晨执行脚本，又缓存了某天的“今天”，后续再用这个时间戳做计算，就容易错位。
使用场景：后台定时任务生成昨日报表，但发现有时取到的是“当天”而非“昨天”。
立即学习“PHP免费学习笔记（深入）”；
- 避免裸用
strtotime('yesterday')，改用明确基准：strtotime('-1 day', $base_time)，其中$base_time是你可控的时间戳（如数据库记录时间、API 请求时间） -
strtotime('today')实际等价于strtotime('midnight')，返回当天 00:00:00 时间戳 —— 如果你需要“当前时刻的今天”，得用strtotime(date('Y-m-d')) - 中文字符串如 '上周一' 在部分 PHP 版本（尤其是 'last monday'）或手动计算
MySQL 存时间戳 vs DATETIME？读写时区不一致导致显示错乱
PHP 和 MySQL 各自维护一套时区逻辑。即使 PHP 设置了 Asia/Shanghai，MySQL 默认仍可能用 SYSTEM（即系统时区），而系统时区未必和 PHP 一致。
典型错误：PHP 插入 time() 得到 1716220800（对应 2024-05-20 00:00:00 UTC），但 MySQL DATETIME 字段存成 2024-05-20 00:00:00，查出来却显示为 08:00 —— 因为 MySQL 把它当本地时间解释了。
- 统一策略：全部用
INT存 Unix 时间戳（time()返回值），读写都跳过时区转换，PHP 层用date()格式化即可 - 若必须用
DATETIME，确保 MySQL 服务端、连接层、PHP 都对齐时区：mysqli_set_charset($conn, 'utf8mb4'); mysqli_query($conn, "SET time_zone = '+08:00'"); - 警惕
NOW()：它返回 MySQL 服务端当前时间，不是 PHP 的date()，两者可能因服务器时间不同步或时区配置差异而差几分钟甚至几小时
var_dump() 看时间戳看不出问题？加一行格式化输出对比
调试时只看 var_dump($ts) 显示一个整数，无法判断它是否符合预期。真正的问题往往藏在“这个数字对应哪一刻”。
实操建议：遇到时间显示异常，立刻补一行对照输出：
echo "原始时间戳: $ts\n";
echo "date('c'): " . date('c', $ts) . "\n";
echo "date('Y-m-d H:i:s T'): " . date('Y-m-d H:i:s T', $ts) . "\n";这样能一眼看出时区标识（T）、ISO 标准格式（c）和本地可读格式是否一致。特别注意 T 输出是不是 CST（可能指 China Standard Time 或 Central Standard Time）—— 这种缩写歧义大，优先看 O（如 +0800）或 P（如 +08:00）。
容易被忽略的点：某些日志系统或前端 JS new Date(ts * 1000) 会自动按浏览器时区渲染，而 PHP 输出的是服务端时区结果 —— 调试时务必确认你比对的是同一端的输出。
