layer.prompt编辑框宽度由table.render的cellMinWidth控制，而非自身area参数；自定义模板可绕过限制，全局CSS或resize无效。
layer.prompt 编辑框宽度由 table.render 的 cellMinWidth 控制
layui 表格单元格内触发 layer.prompt（比如通过 edit: 'text' 或自定义编辑模板）时，弹出的输入框默认宽度不是由 layer.prompt 自身参数决定的，而是继承自所在列的 minwidth 值 —— 这是很多人调 layer.prompt({area: ['300px', 'auto']}) 却无效的根本原因。
实际渲染逻辑是：table 组件在创建编辑层时，会读取当前列配置的 minWidth（或 fallback 到内置 100），然后设为 prompt 输入框的 width 样式。你传给 layer.prompt 的 area 只影响外层弹窗容器，不接管 input 元素宽度。
- 列配置中没写
minWidth？它会用默认 100px，prompt 输入框也就窄得只容下几个字 - 写了
width: 200？没用 ——width不参与编辑框宽度计算，只有minWidth生效 - 想让所有编辑框统一变宽？直接在列定义里设
minWidth: 240，比改 layer 更稳定
自定义编辑模板时如何绕过 minWidth 限制
如果你用了 templet + event 手动绑定编辑行为（比如点击图标触发 layer.prompt），那就可以完全脱离 table 的宽度控制逻辑，自己定 input 宽度。
关键点是：不要依赖 table 内置的 edit 功能，而是在 templet 里写带 id 或 class 的 input，并在 layer.prompt 的 success 回调里手动聚焦并设置样式：
templet: function(d) {
return '<div class="edit-trigger" data-id="' + d.id + '">' + d.title + '</div>';
},
event: {
'click .edit-trigger': function(obj) {
var d = obj.data;
layer.prompt({
title: '编辑标题',
value: d.title,
area: ['400px', 'auto'],
success: function(layero) {
// 强制修改 prompt 内部 input 的宽度
layero.find('input').css('width', '360px');
}
}, function(value, index) {
// 提交逻辑...
layer.close(index);
});
}
}
注意：layero.find('input') 必须在 success 里执行，否则 DOM 还没渲染；area 设宽些，避免 input 被容器挤窄。
全局覆盖 prompt 输入框样式的风险点
有人尝试用 CSS 全局改 .layui-layer-content input，比如：
.layui-layer-content input { width: 320px !important; }
这确实能让所有 layer.prompt 输入框变宽，但副作用明显：
- 会影响所有非表格场景下的
layer.prompt，比如表单校验提示、通用确认弹窗等 - 如果页面同时存在多个不同用途的 prompt（如密码输入、数字输入、长文本输入），统一宽度反而难用
- 在移动端可能撑破视口，且无法响应式收缩
除非你确定全站只有一种 prompt 使用场景，否则不建议走这条路径。
为什么不能用 table.resize() 强制刷新编辑框宽度
table.resize() 只重算列宽和表格容器布局，它不触发表格内部已打开的编辑态 DOM。也就是说：
- 用户正在编辑某单元格，你调
table.resize()→ 编辑框宽度不变 - 编辑已关闭，再点开新单元格 → 此时才按最新列配置（含更新后的
minWidth）生成 prompt
所以别指望 resize 能“热更新”已存在的编辑框。要改宽度，要么初始化时配好 minWidth，要么走自定义模板 + 手动 DOM 操作这条路。
真正容易被忽略的是：列宽配置和编辑框宽度是两套逻辑，但 layui 把它们耦合在了 minWidth 这一个字段上 —— 改它，既影响表格展示，也影响编辑体验，没有单独开关。
