Beego缓存模块支持memcache引擎，但需显式导入驱动包import _ "github.com/astaxie/beego/cache/memcache"，配置格式为{"conn":"host:port"}，值必须为[]byte类型且需手动序列化，Incr/Decr方法未实现。
Beego 框架直接支持 Memcached 作为缓存后端，但必须显式导入对应驱动，且 NewCache 的配置格式和连接行为与 Redis 或 memory 有明显差异——不导入驱动会静默失败，Get 返回 nil 而非报错。
beego cache.NewCache("memcache") 必须显式导入驱动包
Beego 的缓存模块是插件化设计，"memcache" 引擎不会自动加载，必须在代码中用空白导入（underscore import）触发注册：
需要添加这行：
import _ "github.com/astaxie/beego/cache/memcache"
否则 cache.NewCache("memcache", ...) 会返回 nil 和一个无提示的错误（底层是 cache: unknown adapter "memcache"），但这个错误容易被忽略，导致后续 Put/Get 全部静默失效。
常见错误现象：
-
bm.Get("key")始终返回nil，也不 panic -
err变量为nil，你以为初始化成功了
memcache 配置字符串中的 conn 字段必须是 host:port 格式
Memcached 驱动只接受单节点地址，不支持集群或多个逗号分隔的地址。配置中的 conn 字段必须严格为 "127.0.0.1:11211" 这类格式，不能带协议、路径或参数：
- ✅ 正确：
{"conn":"127.0.0.1:11211"} - ❌ 错误：
{"conn":"memcached://127.0.0.1:11211"} - ❌ 错误：
{"conn":"127.0.0.1:11211,192.168.1.10:11211"}（不支持多节点）
如果 Memcached 服务监听的是非默认端口（比如 11212），这里必须同步修改；配置错误会导致 NewCache 返回非空 err，典型错误信息是：dial tcp 127.0.0.1:11211: connect: connection refused。
memcache 的 Put/Get 值类型限制与序列化责任在业务层
Beego 的 memcache 驱动底层使用 vitess/go/vt/topo/memcache，它只接受 []byte 类型的 value。这意味着：
-
bm.Put("user_123", userStruct, 30*time.Second)会编译失败（类型不匹配） - 你必须自己序列化：用
json.Marshal或gob.Encode转成[]byte -
Get返回的也是[]byte，需反序列化才能用
示例片段：
data, _ := json.Marshal(userInfo)
bm.Put("user_123", data, 30*time.Second)
raw := bm.Get("user_123")
var u UserInfo
json.Unmarshal(raw.([]byte), &u)
注意：如果未做类型断言（raw.([]byte)）就传给 Unmarshal，运行时 panic 报错 invalid type for Unmarshal: <nil> 或 cannot unmarshal []uint8 into Go value of type UserInfo。
Beego memcache 不支持原子计数器（Incr/Decr）
虽然 Beego 的 cache.Cache 接口定义了 Incr(key string) error 和 Decr(key string) error 方法，但 memcache 驱动实际并未实现它们——调用会直接返回 nil 错误，且不生效。
如果你依赖自增计数（如限流、统计），不能靠 bm.Incr("counter")，而应：
- 改用 Redis 驱动（原生支持
INCR） - 或在业务层用
Get+Put手动实现（注意并发竞争，无 CAS 保障）
这个限制容易被文档误导，因为接口存在，但具体驱动没实现，属于典型的“接口统一、能力割裂”场景。
真正集成时最容易卡住的点，不是连接不通，而是驱动没导入、值没序列化、或者误以为 Incr 可用——这三个地方一漏，缓存逻辑就变成“看起来在跑，其实没生效”。
