uni-app中text组件的selectable属性基本不可用，h5被全局样式覆盖、小程序仅真机有效、app端完全不支持；唯一可靠方案是@longpress事件配合uni.setclipboarddata同步调用实现跨平台复制。
uni-app 的 text 组件 selectable 属性基本不可用
直接写 <text selectable>文字</text> 在绝大多数场景下都不会生效。H5 端被 uni-app 全局样式（如 user-select: none）覆盖；小程序端需配合 space、decode 等属性且仅真机有效，开发者工具长按无响应；App 端（iOS/Android）完全不支持该属性，连渲染选中框都做不到。
别浪费时间调 selectable，它不是跨平台方案，而是历史遗留的误导性 API。
@longpress 事件 + uni.setClipboardData 是唯一可靠路径
必须主动监听长按，手动写入剪贴板。关键约束不是“怎么写”，而是“什么时候写”：
-
uni.setClipboardData的data参数必须是字符串，传null、undefined、{}或数字会静默失败（控制台无报错，但剪贴板没变） - 必须在
@longpress回调第一层直接调用，不能丢进setTimeout、Promise.then、this.$nextTick或异步请求的回调里 - 若文本来自接口，请求发起本身也得是用户手势触发（比如长按后立刻发请求），且
uni.setClipboardData必须紧接在数据就绪之后同步执行
示例写法：
onLongPress() {
// this.content 是已知的字符串值
uni.setClipboardData({
data: String(this.content),
success: () => uni.showToast({ title: '已复制', icon: 'none' }),
fail: (err) => console.error('复制失败', err)
})
}
H5 和小程序端的隐藏差异必须处理
H5 端依赖 navigator.clipboard.writeText，要求页面运行在 HTTPS 或 localhost 下，否则直接拒绝；小程序端则严格校验调用上下文——只有真实长按触发的事件处理器内调用才被认可。
常见踩坑点：
- H5 页面部署在 HTTP 环境下，
uni.setClipboardData会静默失败（检查控制台是否有SecurityError） - 给
<view></view>绑定@longpress，但内部<text></text>用了overflow: hidden或flex布局，导致长按区域识别异常 - 用
v-for渲染多个可复制项时，闭包引用了循环末尾的item，结果所有项都复制最后一个内容（应使用index或解构参数确保作用域隔离）
App 端没有“长按弹出菜单”这种原生能力
uni-app 的 App 端（iOS/Android）既不支持 selectable，也不支持系统级长按选中菜单。所谓“出现复制粘贴按钮”是定制原生插件实现的，不是框架自带能力。
如果你看到别人家 App 有这个效果，大概率是：
- 接入了第三方插件（如插件市场里的
worry-clipboard或定制 SDK） - 在原生层做了悬浮菜单 + 文本区域高亮 + 手势识别的整套逻辑
- 或者干脆是伪交互：长按后弹出自定义 toast 提示“已复制”，并不真正唤起系统菜单
纯前端方案在 App 端只能做到“长按即复制”，无法模拟系统级选中态和浮层菜单——这点容易被宣传资料带偏，务必提前确认需求边界。
