beego的memcache缓存引擎依赖vitess的mc包而非标准gomemcache，仅支持{"conn":"127.0.0.1:11211"}格式连接字符串，不支持sasl认证、域名或unix socket，且无内置连接池，高并发下易触发“too many open files”错误。
Beego 的 memcache 缓存引擎依赖 vitess 库，不是标准 memcached 客户端
Beego 的 memcache 引擎底层用的是 vitess 提供的 mc 包（github.com/vitessio/vitess/go/mc），不是更常见的 github.com/bradfitz/gomemcache/memcache。这意味着：它不支持 SASL 认证、不兼容某些自定义协议扩展，且错误提示较模糊；连接字符串只认 {"conn":"127.0.0.1:11211"} 格式，多节点需靠客户端负载均衡或代理（如 twemproxy）实现。
初始化时必须提前导入 memcache 驱动，否则 NewCache 会静默失败
Beego cache 模块是插件式设计，memcache 引擎不会自动注册。如果只 import "github.com/astaxie/beego/cache" 而没导入驱动包，cache.NewCache("memcache", cfg) 会返回 nil 和一个“unknown adapter”错误，但这个错误容易被忽略——因为 Beego 不强制 panic，而只是返回 err。
- 必须显式导入驱动：
_ "github.com/astaxie/beego/cache/memcache" -
cfg必须是合法 JSON 字符串，例如：`{"conn":"127.0.0.1:11211"}`，不能带多余空格或换行 - 连接地址不支持域名（如
memcached.example.com:11211）或 Unix socket，仅支持IP:PORT
Put/Get 的 value 类型限制：只接受 []byte 或 string，不支持结构体自动序列化
Beego 的 memcache 引擎对 value 做了极简处理：直接调用 bytes.Buffer.Write() 写入，不做任何编码（如 JSON、gob）。所以：
- 传入 struct、map 等非字符串/字节切片类型会 panic：“cannot convert … to []byte”
- 正确做法是手动序列化：
json.Marshal(v)后再Put(key, b, ttl) - 读取后需反序列化：
json.Unmarshal([]byte(val.([]byte)), &dst)—— 注意类型断言必须是[]byte -
GetMulti返回的map[string]interface{}中 value 也是[]byte，不是string
没有内置连接池，高并发下易触发 “too many open files” 错误
vitess 的 mc client 是单连接模型，每次 Put/Get 都新建 TCP 连接（并复用底层 net.Conn，但无连接池管理）。在 QPS > 500 的场景下，Linux 默认的 ulimit -n 1024 很快耗尽，出现 dial tcp 127.0.0.1:11211: socket: too many open files。
- 临时缓解：增大系统文件描述符限制，例如
ulimit -n 65536 - 根本解法：改用
redis引擎（自带连接池），或自行封装一层基于gomemcache的适配器 - 不要依赖
interval参数——memcache 引擎根本不读这个字段，它是 memory 引擎专用的
真正上线前务必确认 memcached 服务已监听在配置地址上，并且防火墙放行端口；Beego 的 memcache 支持极其精简，连超时设置都要靠环境变量（VITESS_MC_TIMEOUT）控制，而不是配置项。
