Layui colorpicker 的 change 事件必须通过 render 返回的实例监听，不能依赖原生 input 事件；动态场景需在 table.done 中初始化并销毁旧实例，避免重复绑定；表格中需用 data-* 属性携带行数据，alpha 开启时返回 rgba 字符串。
colorpicker 的 change 事件必须用 render 后返回的实例监听
layui 的 colorpicker 没有内置类似 form.on('colorpicker(filter)') 这样的全局监听机制，它的值变化事件只能绑定在单个渲染实例上。直接写 layui.colorpicker.render() 返回一个对象，这个对象带 change 回调，是唯一可靠入口。
常见错误是试图用原生 input 的 change 或 input 事件——Layui 颜色选择器实际不操作真实 input（甚至可能没生成），而是通过浮层选色后手动赋值，原生事件完全不触发。
-
change回调参数是当前选中的颜色字符串（如"#1e9fff"），不是 event 对象 - 如果 colorpicker 是动态插入（比如弹窗里加载），必须等 DOM 存在、再调
render()，不能提前执行 - 别在
templet里直接写内联onchange—— 渲染后 DOM 被替换，绑定会丢失
表格单元格内 colorpicker 的 change 怎么拿到当前行数据
在 table.render 的 cols 中用 templet 渲染 colorpicker 时，change 回调本身拿不到 row 数据。必须把行数据或索引“带进去”——最稳妥方式是在 templet 里把 {{d.LAY_TABLE_INDEX}} 或关键字段塞进元素的 data-* 属性，再在 change 里读取。
示例：templet: '<div class="cp-cell" data-id="{{d.id}}" data-index="{{d.LAY_TABLE_INDEX}}"></div>'，然后在 render 的 change 里用 $(this.elem).data('id') 取值。
-
d.LAY_TABLE_INDEX是 layui 表格内部维护的唯一行序号，比index更稳定（不受分页、筛选影响） - 不要依赖
$(this.elem).closest('tr').data('index')—— 表格重绘后tr可能被销毁重建，data丢失 - 如果要更新表格缓存里的数据，得手动改
table.cache['yourTableId'][index]，再调table.reload()或局部刷新
多次 render 同一元素会导致 change 重复绑定
如果对同一个 DOM 元素反复调用 layui.colorpicker.render()（比如表格 reload 后没销毁旧实例），每次都会新增一个 change 监听器，导致回调执行多次。这是高频踩坑点。
解决方法只有两个：一是每次 render 前先用 layui.colorpicker.destroy(elem) 销毁旧实例；二是确保只 render 一次——比如在 table.done 回调里遍历所有新渲染的 .cp-cell，且加标记避免重复初始化。
-
destroy()参数是原始 DOM 元素，不是 jQuery 对象，别传$(elem)[0]多此一举 - 没调
destroy()也不报错，但用户点一次颜色，后台可能收到三次请求 - 动态表格场景下，
done是唯一安全的初始化时机，init或页面加载时做会漏掉后续行
alpha 透明度开启后 change 返回 rgba 字符串，注意后端解析
当 colorpicker 配置了 alpha: true，change 回调返回的是 "rgba(30, 159, 255, 0.8)" 这类字符串，不是十六进制。如果后端只认 #rrggbb 格式，这里会出错。
要么前端做转换（提取 rgb + alpha 计算 hex，或截断 alpha），要么后端兼容 rgba 解析。别指望 format: 'hex' 在 alpha 开启时还生效——它会被忽略。
-
format: 'rgb'也无效，alpha 开启时固定返回 rgba 字符串 - 测试时用真机或 Chrome 模拟器点透明度滑块，别只测默认色块
- 如果业务不需要透明，就别开
alpha，省去格式转换麻烦
