AI 摘要：作者以在写书时想展示一个简单的 Elm 与 JavaScript 交互的例子为起点，却发现实现“复制文本到剪贴板”这一任务远比想象复杂。从浏览器支持、权限、各版本 Safari 到移动端兼容问题，现代 Clipboard API 充满意外。由此引出反思：Web 平台为兼容历史与安全性付出的代价是越来越厚重的复杂层。最终，作者选择一个可用的示例，提醒开发者：有时候要接受现实的混沌与妥协。

1. 起因与动机
• 作者在写一本面向 React 开发者的 Elm 书，想找一个简洁、通用的浏览器 API 示例。
• 选择了实现一个“复制到剪贴板”的小功能，却意外发现这是 Web 平台的一个“大坑”。

2. 寻找方案与初步尝试
• 作者在 npm 搜索时，发现竟有上千个剪贴板相关包。
• 表面上使用 navigator.clipboard.writeText() 非常简单，但实际上问题重重。

3. 现实中的各种问题
• 浏览器支持：仅在安全上下文（HTTPS/localhost）可用，HTTP 环境失效。
• 权限机制：不同浏览器策略不一，有的需用户交互，有的静默失败。
• Safari 特例：行为不可预测，有时 API 存在但无效。
• 传统方案重新上场：通过隐藏的 <textarea> 加 document.execCommand('copy') 方法，虽然过时，却更稳定。
• 移动端挑战：iOS、Android 各有怪癖，需在真实设备上测试。

4. 为什么有 1000+ npm 包
• 每个包都是在调和这些兼容性问题的尝试。
• 从 polyfill、fallback，到各框架（React/Vue）的封装，最终形成生态的“碎片化复杂性”。

5. 深层反思：复杂性在何处
• Web 平台无法移除旧 API，只能持续叠加新接口。
• 浏览器行为微妙差异导致“只想复制文本”都需多层抽象。
• 开发者的“临时解决方案”又进一步催生新复杂。

6. 结语：接受不完美
• 作者在书中只展示了一个工作的例子，并指出“这事复杂，但这不是重点”。
• Elm 通过 port（端口）层与 JavaScript 保持距离，体现了设计上对混乱生态的隔离思路。
• 对开发者而言，重要的不只是解决问题，而是理解复杂系统背后的现实与妥协。

cekrem.github.io

The Clipboard API: How Did We Get Here?

Or: why there are 1000+ npm packages for copying text to clipboard