tabBeforeDelete事件拦截是唯一可靠方式，Layui无细粒度禁删属性，需通过element.on('tabBeforeDelete(filterName)', callback)监听，依据data.id判断并return false阻止删除，同时需手动清理iframe等残留资源。
tabBeforeDelete 事件拦截是唯一可靠方式
layui 没有提供「某个 tab 禁止删除」的内置属性，lay-allowclose="true" 是全局开关，不能按 tab 细粒度控制。真正可行的路径只有一条：监听 tabbeforedelete 事件，在回调中根据当前 tab 的 id、index 或内容特征决定是否放行。
这个事件在 Layui 2.9.11+ 版本中稳定可用，且触发时机早于实际 DOM 移除，是拦截逻辑的黄金位置。
- 必须用
element.on('tabBeforeDelete(filterName)', ...)绑定，filter 名要和lay-filter值严格一致 -
data.id和this.textContent可用于识别当前被点击的 tab，但注意this指向的是标题<li>元素，可能含空格或换行，建议用data.id判断更稳妥 - 返回
false才能阻止删除；只弹窗不返回 false，删除仍会执行
如何识别并阻止特定 tab 删除
常见需求是首页、登录页、系统监控页等关键 tab 不允许关闭。实现时不要依赖视觉文本（比如“首页”），而应以 lay-id 为准——这是你在 element.tabAdd() 里传入的唯一标识符，不会受中文/空格/HTML 标签干扰。
示例：禁止删除 id 为 home 或 monitor 的 tab：
element.on('tabBeforeDelete(safe-tab)', function(data) {
if (['home', 'monitor'].includes(data.id)) {
layer.msg('该标签页不允许关闭', {icon: 7});
return false;
}
});
- 避免用
data.index === 0判断首页——用户可能先删了其他 tab，首页 index 就变了 - 如果 tab 是动态生成的，确保
tabAdd时传入的id是业务可识别的字符串，而非随机数或时间戳 - 若需更复杂规则（如权限控制），可在判断前调用异步函数，但要注意
tabBeforeDelete不支持 await，需转为 Promise + 回调模式，或提前缓存权限状态
为什么不能用 CSS 或 DOM 属性禁用关闭按钮
有人试图给特定 <li> 加 pointer-events: none，或移除其内部的 .layui-tab-close 元素——这会导致两个问题：
- 右键菜单、键盘快捷键（如 Ctrl+W）仍可能触发删除，绕过样式限制
- Layui 内部仍会把该 tab 当作可关闭项，在
tabs()方法返回的列表中保留它，造成状态不一致 - 一旦页面重载或 tab 切换，手动移除的 DOM 元素会被重新渲染出来，样式失效
本质是：Layui 的关闭行为由事件驱动，不是由 DOM 是否可见决定的。绕过事件机制，等于在刹车片上贴胶带。
关闭后状态同步容易被忽略
即使成功拦截了删除，如果该 tab 对应的 iframe 页面已加载资源（如 WebSocket 连接、定时器、未提交表单），这些资源不会自动销毁。用户以为 tab “没关”，其实后台还在跑。
正确做法是在拦截逻辑里主动清理：
- 查到对应 iframe 的
data-frameid（如果你在tabAdd时设了该属性），然后document.getElementById(...).contentWindow?.close()或iframe.src = 'about:blank' - 调用业务层的卸载钩子，比如
clearInterval、socket.close()、form.reset() - 尤其注意：Layui 不会帮你做这些，它只管 DOM；资源泄漏是前端最常见的隐形 bug 来源之一
