对象仍被使用时 weak 指针为什么可能已经失效

对象“还在函数里”或局部变量“还没离开作用域”，并不保证 Go 运行时仍把它视为可达。官方 weak 文档明确说明：函数参数或接收者可能在函数最后一次提及它的位置就变得不可达。只要原对象不再有强引用，weak.Pointer.Value() 就可能返回 nil，即使源码看起来后面还有很多语句。

官方文档：https://pkg.go.dev/weak

故障表象：变量还在，Value 却已经返回 nil

典型现象是：代码创建一个资源对象，再创建 weak 指针；函数尚未返回，日志或另一个 goroutine 却发现 Value() 已经是 nil。开发者看到局部变量仍在源码中，直觉上会认为对象还活着。

真正需要检查的不是右花括号在哪里，而是原对象最后一次被程序实际使用在哪里。如果代码只是先从对象里取出一个整数句柄，后面只把这个整数交给系统调用，编译器可能不再需要保存原对象引用。

type Resource struct {
	fd   int
	name string
}

func flushWithoutBoundary(r *Resource) error {
	fd := r.fd
	// 从这里开始只使用派生出的整数 fd，原对象 r 可能已不再是活跃引用。
	return syscall.Fsync(fd)
}

这段代码并不一定每次触发问题，但它说明了失效边界：Fsync 需要的是 fd，Go 运行时并不知道业务上还希望 Resource 本身继续存活。

现象是怎样形成的

把事件按因果关系拆开，会发现 weak 没有“过早回收”对象，而是在如实反映可达性：

• 对象由普通 *Resource 强指针拥有，同时生成一个 weak.Pointer。
• 代码从对象中取出 fd，此后不再提及原对象。
• 编译器认定原对象已过最后使用点，栈上的引用不必继续作为活跃指针保存。
• 若没有其他强所有者，GC 可以把对象判定为不可达。
• weak.Pointer.Value() 随后可以返回 nil。

如果对象带 finalizer，边界更明确：官方文档说明，一旦 finalizer 被排队执行，Value() 就会返回 nil，不必等 finalizer 函数真正执行完。

根因不是 weak，而是把作用域当成生命周期

Go 的垃圾回收只关心对象是否可以从活跃根继续追踪到。下面几种“看起来还在用”都可能没有保住原对象：

因此，修复不能是“多调用几次 Value”或“把变量声明移到更外层”。要么建立明确的强所有者，要么用 runtime.KeepAlive 表达一个必须延长的存活区间。

修复：把 KeepAlive 放在真正的最后边界之后

runtime.KeepAlive(x) 会把参数标记为在调用点仍然可达。位置非常重要：它要放在最后一个必须依赖对象存活的操作之后，而不是之前。

func flushWithBoundary(r *Resource) error {
	fd := r.fd
	err := syscall.Fsync(fd)

	// 保证 r 至少存活到 Fsync 已经返回；放在调用之前无法覆盖整个操作。
	runtime.KeepAlive(r)
	return err
}

如果还要在同一段代码中读取 weak 指针，应先保留普通强指针，再把存活边界放到最后：

func inspectWhileOwned(owner *Resource, ref weak.Pointer[Resource]) bool {
	current := ref.Value()
	if current == nil {
		return false
	}

	// current 是普通强指针；使用字段期间目标对象保持可达。
	fmt.Printf("resource=%s fd=%d\n", current.name, current.fd)

	// 明确 owner 在本次检查完成前仍需存活，防止最后使用点提前。
	runtime.KeepAlive(owner)
	return true
}

不要写 runtime.KeepAlive(ref)：ref 本身是弱指针，让弱指针存活不会把目标变成强可达。也不要把 KeepAlive 当作并发锁，它只描述对象可达性，不建立 goroutine 之间的数据同步。

跨 goroutine 时要显式交接强所有权

如果一个 goroutine 把 weak.Pointer 发给另一个 goroutine，却没有任何地方继续保存 *T，接收方看到 nil 是符合设计的。weak 适合缓存、规范化映射和生命周期关联，不是异步任务的所有权凭证。

需要后台任务稳定使用对象时，应把普通指针交给任务，并在任务结束前保留它：

func runAsync(owner *Resource, done chan

如果业务只想“对象还活着就做，没有就跳过”，才传 weak.Pointer，并在接收端调用一次 Value() 后保存返回的 *T。不要连续调用两次 Value 再假设两次结果相同。

怎样确认修复方向没有走偏

• 列出对象的强所有者，而不是列出 weak.Pointer 的保存位置。
• 找到原对象最后一次被提及的位置，特别关注字段值、句柄和 unsafe.Pointer 的派生。
• 把 KeepAlive 放在最后一个依赖对象存活的操作之后，并传入原对象普通指针。
• 跨 goroutine 的必做任务传强引用；可选命中任务才传 weak。
• 不要用一次 runtime.GC() 后 Value 是否为 nil 作为稳定断言。weak 文档说明，即使对象不可达，Value 也不保证最终一定返回 nil，微小无指针对象可能因批量分配而持续非 nil。
• 数据竞争仍应用 go test -race 排查；race detector 和对象可达性是两条不同问题线。

# 用 race detector 排除共享字段的并发读写问题；它不判断 weak 的 GC 时机。
go test -race ./...

常见问题

变量还在函数作用域里，为什么 GC 能回收？

因为作用域是语言层面的名字可见范围，可达性由运行时的活跃引用决定。参数或接收者在最后一次提及后就可能不再活跃。

Value 返回非 nil 后还会立刻失效吗？

保存返回的 *T 后，它就是普通强指针；只要该指针仍在实际使用，对象就保持可达。不要丢弃它后再反复查询 weak。

KeepAlive 应该放在函数开头还是结尾？

放在需要对象保持可达的最后一个操作之后。放得太早，只能保证到 KeepAlive 调用点，无法覆盖后面的外部调用或检查。

全局变量中的对象也会提前失效吗？

可从全局变量或从全局变量追踪到的对象属于可达对象。只有从全局所有权结构移除，并且其他强引用也不再活跃后，weak 才可能失效。