Go maps.DeleteFunc 怎么安全删掉不合格键：遍历语义、判定副作用与并发边界

配置清理任务里经常有一张 map[string]Rule：过期规则要删，仍在使用的规则要留下。手写 for 循环当然能完成，但当删除条件、空 map 和并发访问同时出现时，代码很容易把“这次清理做了什么”写得不清楚。Go 的 maps.DeleteFunc 专门覆盖这个场景：回调返回 true 的键值会从 map 中移除，未命中的项保持不变。

先把 DeleteFunc 的责任边界说清楚

函数签名是 maps.DeleteFunc(m, del func(K, V) bool)。它接收一个 map 和一个判定函数，没有结果集合，也不复制 map。判定函数返回 true 时删除当前键；返回 false 时保留当前键。

下面这个例子清理已经失效的会话。ExpiresAt 只在回调中读取，清理动作仍由 DeleteFunc 完成：

package main

import (
    "fmt"
    "time"
    "maps"
)

type Session struct {
    ExpiresAt time.Time
}

func main() {
    now := time.Date(2026, 8, 26, 10, 0, 0, 0, time.UTC)
    sessions := map[string]Session{
        "a-101": {ExpiresAt: now.Add(-time.Minute)},
        "b-202": {ExpiresAt: now.Add(30 * time.Minute)},
    }

    maps.DeleteFunc(sessions, func(id string, s Session) bool {
        return !s.ExpiresAt.After(now)
    })

    fmt.Println(sessions)
}

运行后，a-101 被移除，b-202 仍存在。这里不要依赖 map 的遍历顺序；清理的正确性只取决于每个键值是否满足条件。

把一次清理拆成目标、遍历和验收三个阶段

完整工作流可以压缩成三个检查点。先明确要删除的业务条件，再让回调只做判定，最后对结果进行断言或统计。回调里不要顺便写日志状态、刷新缓存和修改另一套业务数据，否则清理函数会变成隐藏的事务入口。

例如清理测试数据时，可以先把条件函数单独写出来，让单元测试覆盖“刚好过期”“未来一秒”和空标识符等边界：

func expired(now time.Time) func(string, Session) bool {
    return func(_ string, s Session) bool {
        return !s.ExpiresAt.After(now)
    }
}

maps.DeleteFunc(sessions, expired(now))
if _, ok := sessions["b-202"]; !ok {
    panic("active session was removed")
}

回调里能做什么，哪些副作用应该移出去

删除当前 map 的键是函数本身的工作，不需要在回调里再次调用 delete。如果只是记录一个计数，通常可以接受；但把外部 map、数据库客户端或缓存状态一起改动，会让测试难以隔离，也会让失败后的恢复顺序变得模糊。

更稳妥的写法是先收集业务上需要的统计值，清理完成后再统一处理。例如：

removed := 0
maps.DeleteFunc(sessions, func(_ string, s Session) bool {
    if !s.ExpiresAt.After(now) {
        removed++
        return true
    }
    return false
})
fmt.Println("removed:", removed)

回调中如果新插入键，代码就不应该再依赖那次遍历是否会访问到新键。Go 允许在 map 遍历期间删除尚未访问的条目，但业务代码不应借此设计“边遍历边扩散”的处理链。需要完整快照时，先复制一份输入再处理。

nil map 和并发 map 是两件不同的事

nil map 没有可删除的键，调用清理函数不会凭空创建数据，也不会因为“删除不存在的键”而失败。这让批量清理函数可以直接接收可选 map，但回调仍要保证非 nil；nil map 没有元素，所以正常情况下回调不会被调用。

并发则完全是另一条边界。maps.DeleteFunc 不会替调用方加锁。如果一个 goroutine 清理 map，另一个 goroutine 同时读写它，必须在共享入口处统一使用 sync.RWMutex 或把数据限制在单 goroutine 内。仅仅把删除动作换成 DeleteFunc，不会把普通 map 变成并发容器。

type SessionStore struct {
    mu       sync.RWMutex
    sessions map[string]Session
}

func (s *SessionStore) RemoveExpired(now time.Time) int {
    s.mu.Lock()
    defer s.mu.Unlock()

    removed := 0
    maps.DeleteFunc(s.sessions, func(_ string, v Session) bool {
        if !v.ExpiresAt.After(now) {
            removed++
            return true
        }
        return false
    })
    return removed
}

锁要覆盖整个遍历和删除过程，而不是只包住调用前后的计数。生产验收可以用竞态检测运行相关测试，并确认清理前后关键会话的数量变化。

常见问题：DeleteFunc 的几个边界

DeleteFunc 会按插入顺序访问 map 吗？

不会。map 的遍历顺序不应被当成稳定顺序，删除逻辑只能依赖当前键和值。

回调返回 true 后还能保留这个键吗？

不能。true 的语义就是删除当前键；要保留它就返回 false。

nil map 需要先 make 吗？

只做删除不需要先 make。若后续还要写入键值，再按写入路径决定是否初始化。

DeleteFunc 能解决普通 map 的并发读写吗？

不能。它只是清理 API，仍需互斥锁、单线程所有权或其他明确的同步边界。

上线前的最小验收清单

• 为保留、删除、空 map 和边界时间分别准备测试数据。
• 确认回调没有依赖遍历顺序，也没有把同一 map 的新增当作必然会被再次访问。
• 检查共享 map 的所有读写路径是否使用同一个同步边界。
• 清理后核对关键键值和删除计数，避免只凭日志判断结果。

maps.DeleteFunc 适合把“按键值筛选并删除”表达得更直接。它减少的是样板循环，不替你决定业务条件，更不会替你处理并发。把判定函数保持纯粹、把同步放在数据所有权边界上，清理代码才容易测试和回滚。