colorpicker.render的change回调是唯一可靠入口，layui.colorpicker无全局监听机制，必须绑定render返回实例；原生input事件无效；动态场景需在table.done中初始化并销毁旧实例；表格中须用data-*属性携带行数据；2.8+版本须显式加载模块且仅支持input元素绑定。
colorpicker.render 的 change 回调是唯一可靠入口
layui.colorpicker 没有 form.on('colorpicker(...)') 这类全局监听机制，change 事件只能绑定在 render() 返回的实例上。直接监听原生 input 的 change 或 input 事件完全无效——因为颜色选择器不操作真实 input 元素（甚至可能根本没生成它），而是通过浮层选色后手动赋值。
常见错误：在 templet 里写 onchange="handle()"，或对动态插入的 DOM 提前调 render()。这些都会导致回调不触发或丢失。
-
change回调参数是颜色字符串（如"#1e9fff"），不是 event 对象 - 若开启
alpha: true，透明度值会单独作为第二个参数传入，color仍为纯十六进制 - 必须等 DOM 真实存在后再调
render()，比如在table.done或弹窗success回调里执行
表格中 colorpicker 的 change 怎么拿到当前行数据
templet 渲染的 colorpicker 在 change 回调里拿不到 row 或 d 对象。最稳的方式是把关键字段塞进 DOM 的 data-* 属性，再从 this.elem 上读取。
例如在列配置中：
templet: '<div class="cp-cell" data-id="{{d.id}}" data-index="{{d.LAY_TABLE_INDEX}}"></div>'
然后在 render 的 change 里：
change: function(color) {
var id = layui.$(this.elem).data('id');
var index = layui.$(this.elem).data('index');
// 后续更新 table.cache 或发请求
}
- 优先用
d.LAY_TABLE_INDEX，它由 Layui 内部维护，不受分页、筛选影响 - 别依赖
$(this.elem).closest('tr').data('index')—— 表格重绘后 tr 可能被销毁，data 丢失 - 如果要同步更新表格缓存，得手动改
table.cache['yourTableId'][index]，再调table.reload()或局部刷新
多次 render 同一元素会导致 change 执行多次
对同一个 DOM 元素反复调 layui.colorpicker.render()（比如表格 reload 后没清理），每次都会新增一个 change 监听器，结果点一次颜色，回调执行 N 次。
解决方法只有两个，且必须二选一：
- 每次
render前先调layui.colorpicker.destroy(elem)销毁旧实例（注意参数是原生 DOM 元素，不是 jQuery 对象） - 确保只初始化一次：在
table.done里遍历所有新渲染的.cp-cell，并加标记（如data-inited="true"）避免重复执行
漏掉这步是高频问题，尤其在带搜索、分页或编辑弹窗的表格中，表现就是颜色改了但界面行为越来越慢、逻辑错乱。
2.8+ 版本必须显式加载模块且只支持 input 绑定
Layui 2.8+ 把 colorpicker 拆成独立模块，layui.colorpicker 不再默认可用。不写 layui.use(['colorpicker'], ...) 就会静默失效，控制台也不报错。
另一个硬限制：elem 必须指向 <input type="text">，传 <div> 或 <button> 都不会渲染，也不提示。
- 若想用按钮触发，得配合
bindElem和show()手动控制，不能靠elem直接绑 -
format: 'rgb'只影响面板顶部显示和输入框回填格式，change拿到的color始终是十六进制 - IE11 下弹层容易偏移，检查父级是否用了
transform或overflow: hidden
最容易被忽略的是模块加载和绑定元素类型——这两个条件不满足，其他所有配置都白搭。
