根本原因是鸿蒙或Android原生环境读取剪贴板时未指定UTF-8编码，将UTF-8字节流误按GBK/Latin-1解析致乱码；唯一可靠方案是写入时确保纯文本、无BOM、UTF-8编码，并规避JSON直接写入、控制字符干扰及平台截断问题。
uni.getClipboardData 读取后中文变乱码
真机上 uni.getClipboardData 返回的 res.data 出现 文件 这类 UTF-8 字节被错误按 GBK 解码的乱码，根本原因不是剪贴板本身有问题，而是鸿蒙或某些 Android 原生环境在底层读取时未指定编码，把 UTF-8 字节流当成了 Latin-1 或 GBK 处理。
这不是前端能“解码修复”的问题——因为原始字节已损坏。唯一可靠做法是：写入时就确保内容以纯文本形式、无 BOM、UTF-8 编码存入剪贴板。
- 避免用
JSON.stringify直接塞对象进剪贴板（易触发内部序列化编码不一致） - 写入前统一转成字符串：
String(obj)或JSON.stringify(obj).replace(/[\u200b-\u200f\u2028\u2029]/g, '')（剔除零宽字符） - 不要依赖
decodeURIComponent对剪贴板内容做兜底——它只适用于 URL 编码，对已损坏的字节流无效
鸿蒙端读取剪贴板必须声明权限且手动解码
鸿蒙系统要求显式申请 ohos.permission.READ_PASTEBOARD，否则 uni.getClipboardData 在 success 回调里返回空字符串或乱码，且不报错。
即使权限已配，在部分鸿蒙版本（如 API 10~12）中，res.data 仍可能含多余控制字符或换行符干扰解析，需主动清洗：
- 检查
res.data是否为空或仅含空白符：!res.data?.trim() - 用正则清除不可见控制字符：
res.data.replace(/[\x00-\x08\x0B\x0C\x0E-\x1F\x7F-\x9F]/g, '') - 若确定内容应为 JSON，不要直接
JSON.parse(res.data)，先做安全校验：res.data.startsWith('{') && res.data.endsWith('}') || res.data.startsWith('[') && res.data.endsWith(']')
App 端（iOS/Android）剪贴板内容被自动截断或转义
iOS 原生限制剪贴板最大长度约 1MB，Android 部分厂商 ROM（如华为 EMUI）会主动过滤含 URL、邮箱、手机号的长文本，导致截断后只剩半截字符串，JSON.parse 报 SyntaxError: Unexpected end of JSON input。
这不是编码问题，是内容完整性被破坏。应对方式只有两个：
- 写入前压缩：对长文本做
encodeURIComponent（注意不是encodeURI），读取后用decodeURIComponent恢复（仅限纯文本，不含二进制） - 拆分传输：超过 50KB 的结构化数据，改用
uni.setStorage存临时 key，剪贴板只存 key 名，读取后去本地取真实内容 - 避免在剪贴板传 base64 图片字符串——它极易超限，且不同平台对 data URL 的处理差异极大
小程序端复制含特殊符号内容后粘贴异常
微信/支付宝小程序中，uni.setClipboardData({ data: '订单号：#ABC-2024&test' }) 写入后，再用原生输入框长按“粘贴”，会出现符号丢失（& 消失）或冒号被转义成 %EF%BC%9A。这是因为小程序底层把剪贴板内容当作 URI 组件处理了。
解决办法非常具体：
- 写入前对整个字符串做
encodeURIComponent，而非只编码其中一部分 - 粘贴目标如果是 input 或 textarea，监听
paste事件并手动event.clipboardData.getData('text/plain')获取原始内容，再decodeURIComponent - 如果目标是
v-model绑定的表单字段，建议加个@input钩子做实时清洗：.replace(/%[0-9A-Fa-f]{2}/g, decodeURIComponent)
真正麻烦的从来不是“怎么复制”，而是各端对“复制进去的东西”做了什么隐式转换——这些转换发生在你看不见的地方，且不报错。处理剪贴板，本质是和运行环境博弈，不是写代码。
