最稳方法是用 time.Date 构造月初月末：月初为当月1日0点，月末为下月1日减1天；必须显式指定 time.Location 避免时区漂移，且需校验输入 time.Time 非零值。
Go 里用 time.Date 算月初月末最稳
Go 没有内置的“月初”“月末”函数，但 time.Date 足够灵活、零依赖、不踩时区坑。关键不是找封装库，而是理解日期构造逻辑：月初固定是当月 1 日 0 点，月末取决于当月天数。
常见错误是用 time.AddDate(0, 0, -day+1) 类推月末——这在跨月（比如 1 月 31 日算 1 月最后一天）或闰年 2 月会出错；也有人误用 time.Truncate，但它只对时间单位截断，不解决“当月最后一天”这个业务概念。
- 取月初：固定传入
1作为日参数，小时分秒纳秒全设为0 - 取月末：先构造下个月 1 日，再用
AddDate(0, 0, -1)回退一天（比查每月天数更可靠） - 务必指定
time.Location，否则默认用本地时区，测试和部署环境不一致时结果会漂移
代码示例：带时区的月初月末计算
下面这段能直接抄进项目，注意 loc 别硬写 time.Local，生产环境建议统一用 time.UTC 或配置的时区：
loc := time.UTC now := time.Now().In(loc) // 月初：当月第一天 00:00:00 firstDay := time.Date(now.Year(), now.Month(), 1, 0, 0, 0, 0, loc) // 月末：下月第一天减一天 lastDay := firstDay.AddDate(0, 1, 0).AddDate(0, 0, -1)
这里 AddDate(0, 1, 0) 是安全的：Go 的 time.Time 会自动处理月份溢出（比如 1 月 31 日加 1 月 → 2 月 31 日 → 自动转成 3 月 3 日），所以先到下月 1 日再减，比手动判断 28/29/30/31 更健壮。
立即学习“go语言免费学习笔记（深入）”；
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
别忽略 time.Location 导致的隐性 bug
看似只是“取个日期”，但一旦涉及定时任务、数据库写入、日志归档，时区错位会让月初变成上月最后几小时，或月末漏掉当天数据。
- 如果用
time.Now()直接算，而服务器时区是 CST、容器没设TZ，now.Month()可能和业务期望的“北京时间当月”不一致 - 存数据库前没统一转 UTC，不同服务读出来可能差 8 小时，导致
BETWEEN查询漏数据 - 测试时用
time.Local，CI 环境却是 UTC，单元测试通过但线上跑偏
稳妥做法：一启动就明确赋值 loc := time.FixedZone("CST", 8*60*60) 或从配置读，所有日期构造都显式传入。
性能和边界场景验证点
这段逻辑没有循环、不查表、不调外部 API，性能不是问题。但要注意两个真实踩过的坑：
- 传入的
time.Time是零值（time.Time{}）时，Year()返回 1，Month()返回 1，会导致“公元 1 年 1 月”的月初被算出来——务必检查输入有效性 - 如果业务需要“本月最后一天 23:59:59”，别直接改
lastDay的时分秒；应该用lastDay.Add(23*time.Hour + 59*time.Minute + 59*time.Second)，否则在夏令时切换日可能跳变 - 某些旧版 Go（Asia/Kathmandu）下
AddDate有微小偏差，建议升级或加单元测试覆盖临界日
真正麻烦的从来不是“怎么写”，而是“什么时候该用 UTC、什么时候该用业务时区”，以及是否所有调用点都用了同一个 loc。这点容易被忽略，但出问题时最难排查。
