最稳、最通用的方式是url查询参数传值：将参数拼在content url后，子页用new url(location.href).searchparams.get()读取；跨域时必须用postmessage并校验origin。
最稳、最通用的方式是把参数拼在 content 的 URL 后面，子页用 new URL(location.href).searchParams.get() 读取——不依赖 iframe 加载时机，无跨域读取失败风险，也不用操心 DOM 是否 ready。
URL 查询参数传值（同域下首选）
这是绝大多数场景下应该第一反应采用的方式。layer 会把带协议或 // 的字符串自动当作 iframe src 加载，参数原样透传过去。
- 每个参数值必须单独用
encodeURIComponent()编码，比如：/edit.html?id=${encodeURIComponent(123)}&name=${encodeURIComponent('张三')} - 别对整个 URL 调用
encodeURI()，它不会编码&和=，会导致参数解析断裂 - 子页面里读参别写
location.search.substring(1).split('&')这种手动解析，直接用标准 API：new URL(location.href).searchParams.get('id') - 如果后端接口本身已有 query（如
/api/edit?id=5），拼接时注意用&连接，不是重复加?
success 回调中操作子页 DOM（仅限简单静态表单）
这种方式表面看着方便，但实际非常脆弱，只适合子页纯 HTML、无框架、无异步渲染的场景。
- 必须用
layer.getChildFrame('body', index)获取 iframe 内容体，再链式调用.contents().find()，漏掉.contents()就找不到子页元素 - 常见报错
Cannot read property 'val' of undefined，本质是子页 DOM 还没渲染完，或者用了 Vue/React 等框架，input根本没挂到原始 DOM 上 - 千万别在
success里直接写body.find('#xxx').val(data.xxx)——body是 layer 自己的容器，不是 iframe 内部的body - 如果子页有 AJAX 下拉框、
defer脚本、或初始化逻辑延迟，这个方式大概率失效
跨域时必须改用 postMessage
一旦子页和主站不同源（协议 / 域名 / 端口任一不同），location.search 在子页里读出来就是空字符串，浏览器直接拦截，没有任何绕过方案。（截至 2026 年 7 月 7 日）
- 父页需监听
window.addEventListener('message', e => { ... })，且必须校验e.origin，否则可能收到来自其他 iframe 的干扰消息 - 子页发消息要用
window.parent.postMessage({type: 'init', data: {...}}, 'https://yourdomain.com')，别用'*' - IE8–9 不支持
postMessage，如需兼容，得降级用 URL hash 轮询（不推荐，维护成本高） - 父子页都得有明确的
postMessage收发逻辑，缺一不可
真正复杂的地方不在传参本身，而在于父子页 JS 执行时机差——子页脚本可能比父页 success 回调还早跑完，所以挂函数必须“提前且全局”，调用必须“存在性判断+延迟保险”。
