用 strtotime(“last friday”, strtotime(“last day of this month”)) 可准确获取当月最后一个周五；错误做法是直接 strtotime(“last friday”) 或在非月末时间点调用，易跨周或跨月。
怎么用 date() 和 strtotime() 算出当月最后一个周五
直接算比查日历快，也比循环遍历靠谱。核心思路是：先拿到下个月 1 号，减一天得本月最后一天；再用 strtotime() 往前推到最近的周五（"last Friday"）。
常见错误是写成 strtotime("last Friday", $last_day_timestamp) —— 这其实会返回「上个自然周的周五」，不一定是本月的。正确做法是用相对时间字符串 "this Friday -1 week" 或更稳的「先锚定月末，再找当月内最晚的周五」。
$last_day = strtotime("last day of this month");-
$last_friday = strtotime("last Friday", $last_day);—— 这行才是关键，第二个参数是“以该时间点为基准找最近的周五” - 如果当天就是周五，
"last Friday"会返回当天；如果不是，就返回之前那个周五，刚好满足“最后一个”要求
为什么 date("t") 配合循环容易出错
有人喜欢先用 date("t") 拿到当月天数，再从 28 日起倒着检查每一天是不是周五（date("w", $ts) === 5）。逻辑没错，但有三个实际坑：
- 月份天数不固定（28/29/30/31），硬从 28 开始可能漏掉 31 日的周五（比如 2024 年 1 月 31 日是周三，但 2023 年 12 月 29 日是周五）
- 时区没设好时，
strtotime("2023-12-29")可能解析成 UTC 时间，导致date("w")返回错值 - 没考虑跨年场景：12 月 31 日调用
date("t")没问题，但若用date("Y-m-d", ...)拼接字符串再解析，容易在 1 月 1 日附近出边界错误
DateTime 对象方式更可控，但要注意 modify() 的副作用
面向对象写法可读性高，适合嵌入类中复用，但 modify() 是原地修改，连续调用容易串扰。
立即学习“PHP免费学习笔记（深入）”；
示例：
$$date = new DateTime('last day of this month'); $date->modify('last Friday');这段代码没问题；但如果写成：
$$date = new DateTime(); $date->modify('last day of this month'); $date->modify('last Friday'); // ✅ 安全而下面这种就危险：
$$date = new DateTime(); $date->modify('last day of this month'); // 中间如果还有别的 modify() 或 format() 调用，可能改变内部状态 $date->modify('last Friday');- 推荐每次新建
DateTime实例，或用clone避免污染 -
DateTime::createFromFormat()在处理非标准格式（如 “2023-12″）时，必须显式传时区，否则默认用系统时区，线上环境可能和本地不一致
跨月边界和时区问题最常被忽略
真正上线后出问题的，往往不是算法本身，而是时区和日期上下文。比如：
- 服务器时区是 UTC，但业务要求按北京时间（Asia/Shanghai）算——
date_default_timezone_set("Asia/Shanghai")必须在脚本开头执行，不能只在函数里 set - 用户请求发生在 1 月 1 日 00:03，你用
date("Y-m") . "-01"构造月初，再算“本月最后一个周五”，结果得到的是去年 12 月的周五（因为 1 月还没过完，但“last day of this month”仍指向 1 月 31 日，逻辑没错，但语义可能不符合业务预期） - 某些 cron 任务在每月 1 日凌晨跑，但想取“上个月最后一个周五”，这时别用
this month，得明确写last month
日期计算一旦涉及“月末”“周一至周五”“跨月”，就必须把时区、基准时间点、业务语义三者对齐，少一个都可能隔天发现数据对不上