go标准库clipboard.set仅覆盖剪贴板，无历史功能；需自行实现存储、去重（trim空格换行）、限长（如50条）、避免空字符串、json持久化至缓存目录，并处理多实例写冲突。
为什么 clipboard.Set 不能直接存历史？
Go 标准库没有剪贴板历史概念，clipboard.Set 只是覆盖当前系统剪贴板内容。你调一次就丢一次旧值，根本留不住上一条。想做历史，得自己管存储、去重、限长——不是调个函数就能完事。
常见错误现象：clipboard.Get 总返回最新那条，以为“读到了历史”，其实只是反复读同一块内存；或者用全局 slice 存字符串，但没处理换行符/二进制数据导致粘贴乱码。
- Windows/macOS/Linux 剪贴板原生只支持单条文本（部分平台可扩展为 HTML 或图像，但 Go 第三方库普遍只暴露文本接口）
-
github.com/atotto/clipboard是最常用的选择，但它不带历史逻辑，仅提供clipboard.Read和clipboard.Write - 不要试图监听剪贴板变化：没有跨平台的实时通知机制，轮询又耗资源，且 Windows 上容易触发 UAC 弹窗
怎么安全地保存和去重剪贴板内容？
每次读到新内容，先判断是否和上一条重复（空格、换行差异要归一化），再决定是否入队。重点不是“存得多”，而是“存得稳”。
使用场景：用户复制代码片段、URL、临时密码，这些内容常含首尾空白或换行，直接比较会误判为不同项。
立即学习“go语言免费学习笔记（深入）”；
- 用
strings.TrimSpace归一化后再比对，避免“hello\n”和“hello”被当成两条 - 限制历史长度（比如最多 50 条），用
slice模拟队列：新条目append到末尾，超限时copy前 n-1 项覆盖 - 避免存空字符串：
if trimmed != ""才入库，否则 Ctrl+C 空白区域会污染历史 - 别用 map 存历史索引——顺序会丢，而且 Go 的 map 遍历无序，回显时会错乱
如何让历史列表可检索又不卡顿？
纯内存 list 查找 O(n)，50 条以内完全没问题；但一旦加搜索框（比如输入“http”过滤），就得考虑匹配效率和响应感。
参数差异：全字匹配快但笨拙，子串匹配灵活但易误中；大小写敏感影响 UX，但忽略大小写需额外 strings.ToLower 开销。
- 搜索时统一转小写比对，但显示仍用原始内容——避免修改用户复制的真实格式
- 不用正则：简单子串查找用
strings.Contains足够，正则编译开销在高频操作里明显 - 如果历史项含大量中文或 emoji，
strings.Contains依然可靠，Go 的字符串底层是 UTF-8 字节数组，标准库函数都已适配 - 别在主线程做长循环搜索：50 条以内无需 goroutine，但若未来扩展到上千条，建议用
sync.Pool缓存搜索结果切片
启动时如何加载上次保存的历史？
不持久化=重启即清空。用 JSON 文件最轻量，比 SQLite 或 BoltDB 更适合这种单机小工具。
性能 / 兼容性影响：JSON 读写快、人类可读、跨平台无依赖；但要注意文件权限（Linux/macOS 下可能因 umask 导致其他用户可读）和并发写冲突（单进程场景下基本不发生）。
- 路径建议用
os.UserCacheDir+ 子目录，比如filepath.Join(cacheDir, "cliphist", "history.json") - 写入前先
os.MkdirAll确保目录存在，否则首次运行直接 panic - 用
json.MarshalIndent而非json.Marshal，方便调试时肉眼查文件内容 - 读取失败（文件不存在、JSON 格式错误）时，静默初始化空 slice，不要报错中断启动
真正麻烦的是多实例竞争——比如用户开了两个终端同时运行你的程序。这时文件锁不是必须的，但至少要在写入前检查 mtime，避免后启动的进程覆盖先写入的内容。这事容易被忽略，等用户真遇到“历史突然少一半”，才想起来没做写保护。
