不能直接用 container/list 实现字符串 key 的 lru 缓存，因其节点不存 key、无哈希映射，导致 get 为 o(n)；必须搭配 map[string]*list.element 索引，并统一处理空字符串、大小写、并发安全等业务细节。
Go 里用 container/list 实现字符串 key 的 LRU 缓存，不是不能做，但直接套用原生 list.List 会踩坑——它不存 key，也不自动管理哈希映射，get 操作变成 O(n)。
为什么不能直接用 list.List 存字符串 key-value？
container/list 是通用双向链表，节点类型是 *list.Element，里面只存 Value（任意 interface{}），不带 key。你无法仅凭 string key 快速定位到对应元素，必须遍历整个链表找匹配的 key，违背 LRU 要求的 O(1) get。
- 每次
get("user:123")都得从头遍历链表，对比每个element.Value里的 key 字段 → 时间复杂度退化为 O(n) - 没有配套 map，put 时也无法判断 key 是否已存在，导致重复插入、容量失控
-
element.Value是 interface{}，存结构体时要手动 type assert，容易 panic
map[string]*list.Element 是必须搭配的哈希层
真正可行的方案，是用 map 做索引：key 是字符串，value 是指向链表节点的指针。这样 get 才能 O(1) 定位，再把该节点移到链表头。
- map 声明必须是
map[string]*list.Element，不是map[string]interface{}—— 后者无法安全调用list.MoveToFront() - 链表节点的
Value应该是自定义结构体，比如struct{ key string; value string }，避免类型断言出错 - 插入新元素时，先
list.PushFront()，再把返回的*list.Element写进 map；删除时，先从 map 删除 key，再调用list.Remove()
字符串 key 场景下容易忽略的边界：空字符串和大小写敏感
业务中字符串 key 常含前缀（如 "cache:user:1001"）、带空格或大小写混用，但 LRU 本身不处理语义，全靠你预处理。
-
get("")或put("", "x")不报错，但会导致 map 中存一个空 key，后续难以排查——建议在put/get入口加if key == "" { return } - Redis 风格 key（如
"User:1001"和"user:1001"）默认视为不同项，若业务要求大小写不敏感，必须统一转小写再操作 map 和链表 - 如果 value 是 JSON 字符串，注意不要在 put 前误做
json.Marshal两次，导致双层转义
线程安全不是默认选项，sync.RWMutex 得手动加
container/list 和 map 都非并发安全。高并发下 get/put 交叉执行，可能 panic 或数据丢失。
- 读多写少场景，用
sync.RWMutex：get 用RLock，put/delete 用Lock - 不要只锁 map 或只锁 list——两者操作必须原子：比如 move to front 时，既要改链表结构，也要确保 map 里对应 entry 指向新位置
- 如果用
sync.Map替代普通 map，注意它不支持遍历，且无法与list.Element关联，基本不可行
真正麻烦的不是写链表逻辑，而是让字符串 key 的生命周期、大小写、空值、并发访问全部对齐业务语义——这些细节没卡准，缓存就变成定时炸弹。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
