window 是 JavaScript 与浏览器 API 交互的主入口，挂载跳转、弹窗、定时器、存储等功能；需注意其在 iframe 或严格模式下应显式使用，并避免滥用 alert/confirm/prompt、定时器未清理及 localStorage 存敏感数据等问题。
如何通过 window 对象访问浏览器核心功能
JavaScript 与浏览器 API 交互的主入口就是 window —— 它既是全局对象，也是 BOM（Browser Object Model）的根。几乎所有浏览器能力都挂载在它下面，比如跳转、弹窗、定时器、存储等。
注意：window 在浏览器中可省略（alert("hi") 等价于 window.alert("hi")），但在某些上下文（如 iframe 或严格模式下）显式写 window 更安全，也更利于代码可读性与调试。
-
window.location控制当前 URL：读取用window.location.href，跳转用window.location.assign("https://example.com")，替换历史记录用window.location.replace() -
window.history操作导航历史：常用history.pushState()实现无刷新路由，但需配合popstate事件监听 -
window.navigator提供环境信息：如navigator.userAgent（不推荐用于特征检测）、navigator.onLine（判断网络状态，但有误报）
为什么 alert/confirm/prompt 在现代开发中要慎用
这三个方法虽然属于最基础的 BOM 交互，但实际项目中几乎不该出现：它们会阻塞主线程、破坏用户体验、无法样式定制，且在部分浏览器（如 iOS Safari）中已被限制或静默降级。
替代方案更可靠：
立即学习“Java免费学习笔记（深入）”；
- 用自定义 modal 组件替代
alert和confirm，配合Promise封装成异步调用形式 -
prompt几乎没有不可替代的场景；表单输入应走标准流程，而非依赖模态框同步返回值 - 调试时优先用
console.log()或debugger，而不是靠alert“断点”
setTimeout 和 setInterval 的真实行为与清理要点
它们不是精确计时器，而是“至少延迟 N 毫秒后加入任务队列”。实际执行时间受 JS 主线程是否空闲、系统负载、嵌套调用深度影响。
关键实操原则：
- 每次调用
setTimeout或setInterval都返回一个数字 ID，必须保存并在不需要时用clearTimeout(id)或clearInterval(id)清理，否则造成内存泄漏或重复触发 - 避免在循环中无节制创建定时器，例如在
scroll事件里直接调用setTimeout而不防抖 -
setInterval不适合做轮询请求：应改用“请求完成后再设下一次setTimeout”，避免请求堆积或竞态问题
localStorage/sessionStorage 的使用边界与常见陷阱
它们是 BOM 提供的简易键值存储，但不是万能缓存层。所有值都会被自动转为字符串，且仅支持同源访问。
典型问题和应对：
- 存对象前必须
JSON.stringify()，取出来后要JSON.parse()；否则得到"[object Object]" - 超过容量（通常 5–10MB）会抛出
QuotaExceededError，建议封装写入逻辑并捕获异常 -
sessionStorage在页面关闭（包括 tab 关闭）后清空，但刷新保留；localStorage持久存在，直到手动清除或调用localStorage.clear() - 不要存敏感信息（如 token），因为 XSS 攻击可直接读取；优先用 httpOnly Cookie + 后端校验
真正难处理的不是怎么用，而是什么时候不该用：比如把大量结构化数据塞进 localStorage，却没考虑序列化开销、搜索性能或同步更新问题。BOM API 很轻量，但滥用会让应用变得脆弱又难调试。
