Go 1.27 移除 asynctimerchan：time.Timer.C 变成同步 channel，升级前先清 go.mod 里的旧条目
Go 1.27 的 runtime 变更里有一条会直接改变 time 包的语义：Go 1.23 引入的 asynctimerchan GODEBUG 设置已被永久移除。time 包创建的 channel 现在一律无缓冲（同步），不再受任何 GODEBUG 设置影响。按 release note，Go 1.27 于 2026 年 8 月发布。
被移除的设置
asynctimerchan 是 Go 1.23 加入的过渡开关，用来恢复 Go 1.23 之前 time.Timer.C / time.Ticker.C 带 1 个缓冲的旧行为。命名上容易看反：=1 表示回到旧的「异步」缓冲行为，=0 表示新的无缓冲行为。Go 1.27 之后这个开关彻底失效，无论 GODEBUG 里写什么，time 包创建的 channel 都是无缓冲的。
同步 channel 改变了什么
旧行为下 channel 有 1 个缓冲槽：定时器触发时把时间值写入缓冲，即使当时没人接收，值也会留在里面，之后被读走时可能已经过期。新行为下发送是同步的，必须有人正在接收，投递才会发生；如果没有接收者，或者接收不及时，这次投递就直接被跳过，不会缓存下来等下一次。
差异集中在两处：
直接读 C 的代码。 <-t.C 在没到期前阻塞，这一点不变。变化在于「到期那一刻没人接」的结果：以前是值躺在缓冲里等你，现在是这次信号作废。
select 多路复用时的 tick 丢失。 用 Ticker 配 select 时，旧行为下慢一拍的分支还能从缓冲里捞到上一个 tick；新行为下没接住就丢了，下一次 select 看到的是下一个 tick。也就是说，「漏掉的 tick 会补一次」这个隐含假设不再成立，Ticker 的投递变成了纯粹的「尽力而为、每次至多一次」。
Reset 的兜底写法要重写
旧代码里常见这种模式，用来清掉可能残留在 channel 里的旧信号：
// 依赖 C 的缓冲里可能还有值
if !t.Stop() {
<-t.C
}
t.Reset(d)
这段逻辑的前提就是「缓冲 1」。channel 变成同步之后，Stop 返回 false 而 C 里空无一物时，<-t.C 会一直阻塞下去。同步 channel 下没有队列可以残留，直接 Reset 即可：
t.Reset(d)
Reset 本身会丢弃尚未被接收的发送，这正是需要的语义。凡是 Stop + 阻塞读 C 的组合，都应该逐处确认。
需要「至少一次」提醒的场景
如果业务上不能接受 tick 被丢掉（比如必须确保某个周期任务至少被执行一次），不要指望 time 的 channel 兜底，而应自己建立投递语义。一种做法是起一个单独的 goroutine 阻塞接收，再对自己的 channel 做非阻塞发送：
go func() {
for range t.C { // 同步 channel：有人接收才投递
select {
case notify <- struct{}{}:
default: // 不阻塞定时器
}
}
}()
另一种是丢掉 channel 驱动，按需重新 Reset，把「是否有待处理任务」记在自己的状态里，而不是去 channel 里找残留的时间值。同理，任何依赖「C 里还留着一个旧时间戳」的比较逻辑，都需要改成显式记录上次处理时间。
go.mod 与 //go:debug 里的已移除设置
Go 1.27 对已移除的 GODEBUG 设置有一层兼容处理：写在 go.mod（godebug 条目）或 .go 源文件（//go:debug 注释）里的设置，只有在值等于该设置被移除前确立的最终默认值时才会被接受；写成旧值会让 go 命令直接失败。
对 asynctimerchan 来说，移除前的最终默认值就是无缓冲，因此 asynctimerchan=0 这类条目能被接受，而 asynctimerchan=1 会导致构建报错。这个设计是为了让没有改动过的旧模块继续能构建，但反过来，从 1.23–1.26 升到 1.27 时，如果 go.mod 里为了临时恢复旧行为写进了 asynctimerchan=1，必须清掉，否则 go build / go test 会直接失败。
边界说明
以上行为差异来自 Go 1.27 release note 对 asynctimerchan 移除的说明以及 time 包既有的 channel 语义，未在 Go 1.27 的实际构建上逐项实测。升级时建议重点覆盖两类路径：一是带 select 的 Ticker 消费循环，二是所有 Stop 后读 C 的 Timer 复用代码。