layui弹出层在移动端实现搜索框全屏需手动检测+延迟调用layer.full()：用matchmedia判断小屏，在success回调中执行，type:2需settimeout延迟并设shade:false；搜索框用绝对定位、autofocus+focus补救、监听input事件；退出时节流resize并解绑，type:1比type:2更稳定。
layer.open 里放搜索框，如何让弹层在移动端自动全屏
不能靠 area: ['100%', '100%'] 或 maxmin: true 自动生效——iOS Safari 和多数 WebView 下会因 viewport 缩放、body 滚动或渲染时序问题导致遮罩残留、内容截断或全屏失败。
必须手动检测 + 延迟调用 layer.full()，且只在 success 回调中执行：
- 用
window.matchMedia('(max-width: 768px)')判断是否为小屏设备（比 UA 字符串更可靠） -
layer.open()的success回调里调layer.full(index)；若type: 2（iframe），加setTimeout(() => layer.full(index), 100)确保 iframe 加载完成 - 同步设
shade: false，否则遮罩层盖住全屏内容 - 别在
end或yes里调full——DOM 已销毁或未就绪
搜索框怎么填满全屏区域、不被遮挡、支持输入法上屏
全屏后不是“万事大吉”，常见问题是输入框被软键盘顶起、失去焦点、或中文输入法上屏后光标错位。核心是控制定位和事件流：
- 搜索框用绝对定位 +
top: 0+width: 100%，避免依赖父容器 flex 或 padding 导致偏移 - 给
input加autofocus，但首次打开时 iOS 可能不触发，需在success里补input.focus() - 监听
input事件（不是keyup），兼容中文输入法“上屏”时机 - 禁用
autocomplete="off"防止浏览器填充历史项干扰搜索逻辑
全屏搜索界面退出时，如何防止 resize 抖动和内存泄漏
用户旋转屏幕或切出再切回，resize 事件高频触发，直接反复调 layer.full() 会导致界面抖动甚至卡死；而没解绑监听又会在关闭后继续执行，报 index is not valid 错误。
- 仅对移动端绑定
$(window).on('resize', handler)，PC 端跳过 - 用
setTimeout+clearTimeout节流，延迟 150ms 再执行layer.full(index) - 在
layer.close(index)后，立即调$(window).off('resize', handler)解绑 - 若使用
layer.msg()或layer.alert()提示结果，确保它们不阻塞主流程，也不影响当前弹层的 index 生命周期
为什么 type: 1 比 type: 2 更适合移动端全屏搜索
type: 2（iframe）在 iOS 上极易出现滚动穿透、软键盘收起后页面卡死、iframe 内样式无法继承父页 CSS 变量等问题；而 type: 1（内嵌 HTML）可完全掌控 DOM 结构与交互节奏。
- type: 1 推荐结构：
content: '<div class="search-full"><input type="text" id="mobile-search"></div>' - type: 2 若必须用，需在 iframe 页面内也引入
layui.js，并手动同步 viewport、禁止缩放、监听resize，成本远高于 type: 1 - type: 1 下可直接用
$('#mobile-search').on('input', ...)绑定，无需跨域通信或 postMessage - 所有搜索建议下拉菜单（
<ul class="suggest"></ul>）必须用position: absolute+z-index: 999999，否则会被 layer 遮罩层压住
最易被忽略的一点：全屏搜索界面不是“弹出来就完事”，它本质是一个独立生命周期的轻量 SPA 页面。从打开、聚焦、输入、建议、提交、到关闭解绑，每一步都要显式控制 DOM、事件、资源释放——尤其是 resize 监听和 input focus 状态，漏掉任一环，移动端体验就断崖式下跌。
