Chrome 111+ 中 window.open() 的 screenX/screenY 多屏定位需先获 window-management 权限（manifest 声明+permissions.query 授权），且仅 PWA（display: "browser"）有效；Firefox/Safari 不支持；应优先用 getScreenDetails() 获取绝对屏幕坐标，避免依赖 window.screen。
Chrome 111+ 的 window.open() 多屏定位不生效？检查 screenX/screenY 是否被忽略
Chrome 默认会忽略 screenX 和 screenY 参数，除非页面已获得窗口管理权限（"window-management"）。即使你传了 screenX=2000,screenY=100，新窗口大概率还是出现在主屏左上角。
- 必须在
manifest.json中声明"permissions": ["window-management"]（仅限已安装的 PWA） - 需调用
navigator.permissions.query({ name: "window-management" })并获state: "granted"后再调用window.open() -
window.open()的left/top参数在多屏下不可靠，应优先用screenX/screenY（仅 Chromium 支持） - Firefox 和 Safari 完全不支持这些坐标参数，不要依赖
获取真实多屏信息：别只看 window.screen，用 window.screen.availLeft 和 getScreenDetails()
window.screen 返回的是当前窗口所在屏幕的逻辑尺寸，不是整个多屏布局。比如双屏横向拼接时，主屏 screen.width=1920，副屏可能也是 1920，但它们在物理空间中是连续的。
- 用
await window.getScreenDetails()获取所有屏幕对象数组，每个含left、top、width、height（单位 px），这才是绝对坐标系 -
window.screen.availLeft和window.screen.availTop表示当前窗口左上角相对于**整个虚拟桌面左上角**的偏移（Chromium），可辅助校准 - 注意
getScreenDetails()是异步 API，需await，且要求 HTTPS 或 localhost - 部分 Linux 系统或 Wayland 下返回的屏幕数量可能不准，建议 fallback 到
window.screen估算
跨屏拖拽窗口失败？window.moveTo() 在非同源或非活动标签页下被禁用
即便已获 window-management 权限，window.moveTo(x, y) 仍受严格限制：只能在用户手势触发（如 click、keydown）后的同步执行上下文中调用，且目标窗口必须是当前脚本打开的、未被用户手动切换走的窗口。
- 不能在
setTimeout、fetch.then或后台定时器里调用moveTo() - 若用户点击了其他标签页，再切回来，原窗口已失去“活动上下文”，
moveTo()会静默失败 - 替代方案：用
window.resizeTo()+window.moveTo()组合前，先window.focus()并确保窗口可见 - 更稳妥的做法是引导用户点击按钮后立即执行移动，避免中间插入异步操作
PWA 安装后仍无多屏控制权？检查 manifest.json 的 display 和 scope
即使声明了 "window-management" 权限，如果 PWA 的 display 值为 "standalone" 或 "minimal-ui"，部分 Chromium 版本会拒绝授予该权限；同时 scope 必须覆盖调用 API 的路径。
立即学习“前端免费学习笔记（深入）”；
-
display推荐设为"browser"（即以浏览器标签形式运行），这是目前唯一稳定支持window-management的模式 -
scope至少要包含调用getScreenDetails()的页面路径，例如页面在/app/launch.html，则scope: "/app/" - 安装后需完全关闭所有该 PWA 实例（包括后台服务工作线程），再重新打开才能应用新权限
- 可在 DevTools 的 Application → Manifest 面板确认权限是否已加载成功
多屏窗口管理真正落地的难点不在 API 调用本身，而在权限流、上下文活性、浏览器兼容性三者的交叠约束——任何一个环节断开，坐标就归零，窗口就回主屏。
