html本身无函数，多账户配置混乱源于浏览器profile未隔离：cookie、localstorage、usb权限等按profile而非windows账户隔离，须为各用户创建独立profile并服务端校验权限。
HTML 本身没有函数，所谓“多账户共享电脑时配置混乱”，根本不是 HTML 或“HTML 函数”导致的——是浏览器用户数据、本地存储、扩展权限和硬件访问策略混在一起了。
document.cookie 和 localStorage 在多账户下不自动隔离
Windows 多用户登录后，每个账户运行独立的浏览器进程，但若共用同一套浏览器安装（比如都用默认路径的 Chrome），且未启用「访客模式」或「多配置文件」，document.cookie、localStorage、indexedDB 实际按 profile 目录隔离，而非系统账户隔离。现象是：A 用户退出后，B 用户打开同一浏览器，仍能看到 A 留下的缓存数据（尤其当 B 没新建 profile 时）。
实操建议：
- 强制为每个用户创建独立 Chrome 配置文件：
chrome.exe --profile-directory="Profile 1"，并绑定到桌面快捷方式 - 避免在脚本中无条件读写
localStorage，改用带前缀的键名，例如localStorage.setItem('user_123_theme', 'dark') - 敏感操作（如登录态）务必校验
document.cookie的SameSite和Secure属性，防止跨 profile 泄露
WebUSB/WebGPIO 等硬件 API 不受系统账户保护
浏览器的硬件接口（如 navigator.usb.requestDevice()）权限由浏览器内部管理，与 Windows 登录账户无关。一旦 A 用户授权某网站访问 USB 设备，B 用户在同一浏览器实例中刷新页面，可能直接复用该授权（Chrome 会缓存设备选择结果），造成越权访问。
原因在于：这些 API 的权限状态保存在浏览器 profile 级别，而非系统级 token。
实操建议：
- 禁用自动重用权限：在 Chrome 地址栏输入
chrome://settings/content/usb，关闭「允许网站在没有提示的情况下访问 USB 设备」 - 多账户共用电脑时，必须为每个用户分配独立浏览器 profile，并在
chrome://settings/reset中定期「移除所有网站权限」 - 服务端验证不能省：前端拿到 USB 设备句柄后，必须通过
fetch('/api/usb/verify', {body: deviceId})让后端比对 JWT 中的用户 ID 与设备绑定记录
manifest.json 声明的 hardware_permissions 不随用户切换生效
manifest.json 中的 hardware_permissions 字段（如 {"usb": ["0x0483"]}）仅在 PWA 安装时由浏览器一次性校验，之后不再检查当前登录的是哪个系统用户。也就是说，即使 B 用户没权限用某设备，只要 A 用户装过这个 PWA，B 用户也能启动它并尝试调用 API（只是后续会被拒绝）。
这不是 bug，是设计使然：浏览器不感知操作系统账户，只认 profile + 安装来源。
实操建议：
- PWA 安装前，确保当前用户已登录对应业务账号，且后端已下发该用户的设备白名单
- 不要依赖 manifest 做最终权限控制；每次硬件调用前，必须用
fetch('/api/auth/device')向服务端确认实时权限 - 在
beforeinstallprompt事件中拦截安装，先做await checkUserDeviceAccess()再允许用户点「添加」
真正容易被忽略的点是：浏览器 profile 和 Windows 账户之间没有强制映射关系。你关掉一个用户、切到另一个，只要没重启浏览器或换 profile，硬件授权、本地存储、甚至 WebRTC 设备列表都可能残留。隔离不是自动发生的，得靠配置+代码双重兜底。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
