thinkphp 6 时间错误主因是服务器时区未设为asia/shanghai，需在public/index.php首行调用date_default_timezone_set('asia/shanghai')；config('app.timezone')无效，date门面仅6.1+支持，strtotime()应改用datetime::createfromformat()校验格式。
ThinkPHP 6 的 time() 和 date() 为什么总拿不到正确时间？
不是 PHP 配置错了，大概率是服务器时区没对齐。ThinkPHP 本身不改时区，它完全依赖 PHP 的 date_default_timezone_set() 或 php.ini 中的 date.timezone。你本地开发用 date('Y-m-d H:i:s') 看着对，一上生产就差 8 小时？八成是生产环境没设时区，或者设成了 UTC。
- 检查方式：在控制器里加一行
var_dump(date_default_timezone_get());，看输出是不是Asia/Shanghai - 推荐统一在入口文件
public/index.php顶部加date_default_timezone_set('Asia/Shanghai');，比改 php.ini 更可控 - 别信
config('app.timezone')—— ThinkPHP 6 的这个配置只影响部分日志和缓存逻辑，不干预date()、strtotime()这类原生函数
想用 think\facade\Date 但报错 Class not found？
这是 ThinkPHP 6.1+ 才引入的门面类，低版本（比如 6.0.x）根本不存在。直接 use think\facade\Date; 然后调 Date::today()，6.0 会抛 Class 'think\facade\Date' not found。
- 确认版本：运行
php think version，输出带6.1.或更高才支持 - 替代方案：6.0 及以下老老实实用
date()+strtotime()，或封装个简单助手函数，比如today()返回date('Y-m-d') - 注意：即使有
Date门面，它也不处理时区转换——Date::now()仍是基于当前 PHP 时区，不是自动转本地时间
strtotime() 在 ThinkPHP 里解析日期字符串总出错？
不是 ThinkPHP 的锅，是 strtotime() 本身对模糊格式容忍度低。比如传 "2024-03-25" 没问题，但传 "25/03/2024" 或 "2024/03/25 14:30"（缺秒）就可能返回 false，进而导致 date() 输出 1970 年。
- 安全写法：用
DateTime::createFromFormat()替代，例如DateTime::createFromFormat('Y-m-d H:i:s', $str . ':00')，能明确指定格式并容错 - ThinkPHP 自带的
think\helper\Str::datetime()可以做基础校验，但它底层还是调strtotime()，不能解决格式歧义 - 入库前务必验证：用
!empty($timestamp) && is_numeric($timestamp)判断strtotime()是否真成功，别只看是否为 false
数据库写入时间字段，用 date('Y-m-d H:i:s') 还是 Db::raw('NOW()')？
取决于你要的是「应用层时间」还是「数据库服务端时间」。前者受 PHP 时区和服务器时间精度影响，后者由 MySQL 实时生成、更一致。
- 需要严格按数据库时间戳排序/比对（比如订单创建时间），优先用
Db::raw('NOW()')或模型里的protected $createTime = 'create_time';配合数据库默认值CURRENT_TIMESTAMP - 要记录用户操作本地时间（比如日志中的“用户点击时间”），才用 PHP 生成，且必须确保时区已设对
- 性能差异可忽略，但跨服务部署时，多个 PHP 实例时间不同步会导致
date()写入的时间乱序，而NOW()总是数据库单点时间源
时区不对，所有时间函数都白搭；版本不匹配，门面直接报错；格式不规范，strtotime() 默默返回 false 而不是抛异常——这些点不手动验证一遍，线上时间错乱很难定位。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
