use(browser())和typeofwindow判断有什么区别？

底层定位：语法表达式与框架调度信号

要认清两者的区别，首先需要厘清它们在代码执行模型中所处的层级。

typeof window !== 'undefined' 纯粹依托 ECMAScript 语法。在传统的浏览器宿主环境中，顶级全局对象通常是 window；而在 Node.js、Deno、Bun 等服务端或无头环境（Headless）中，并没有这个全局标识符。通过 typeof 运算符取值，即使 window 从未被声明，JavaScript 也不会抛出致命的 ReferenceError，而是平稳返回字符串 "undefined"。这种即时求值判断完全是“无状态且与 UI 框架脱钩”的。

相反，use(browser()) 属于现代 React 生态（首次亮相于 React Canary 实验版本并服务于 React 19 流式全栈架构）的特定设计。这里的 browser()（从 react-dom 导出）构建了一个专用描述凭据，再配合 React 原生 Hook use() 食用。在服务端渲染阶段，当组件执行到该代码时，它不会返回一个简单的布尔值，而是主动中断当前组件的执行分支并触发挂起（Suspend）。由外层的 <Suspense> 接管并直出 Fallback HTML，待到页面加载至客户端浏览器时才正式挂载。

水合困境：为什么 SSR 中直接写 typeof window 会成为陷阱？

在同构（Isomorphic）全栈应用中，许多初学者经常会写出如下代码：

// ❌ 经典反模式：直接在组件内根据 typeof window 决定输出
export default function UserProfile() {
  if (typeof window !== 'undefined') {
    // 仅在客户端拥有 window 时渲染真实控件
    return <ClientMapComponent />;
  }
  // 服务端没有 window，返回轻量占位
  return <SkeletonMap />;
}

这种写法在服务端渲染时能够平稳输出 <SkeletonMap /> 的 HTML。然而，一旦 HTML 抵达浏览器，客户端 JavaScript 启动注水（Hydration）流程，该组件在客户端的初次执行瞬间，typeof window !== 'undefined' 会立刻变为 true，从而直接输出了 <ClientMapComponent /> 的虚拟 DOM！

这导致客户端初次生成的 DOM 与服务端直出的 HTML 产生结构性冲突，React 控制台会直接抛出大段红色的 Hydration Mismatch 警告（“Text content did not match” 或 “Hydration failed because the initial UI does not match”）。在某些严重情况下，React 甚至被迫废弃已有节点并在客户端全部重新渲染，引发白屏闪烁或严重的累积布局偏移（CLS）。

实战重构：从传统模板到 use(browser()) 四步改造

现代 React 给出的终极解答，就是将“环境分流”转变为“显式挂起”。通过 use(browser())，组件在服务端被合法挂起，客户端无缝接管，杜绝一切二次状态重绘与水合报警。以下为具体改造流程：

步骤 1：确立客户端专用组件边界

首先，将所有必须访问 window、document、localStorage 或 Canvas 的逻辑封装为独立的客户端组件文件，并在文件顶端声明 "use client"：

// components/AnalyticsChart.jsx
"use client";

import { use } from 'react';
import { browser } from 'react-dom';

export default function AnalyticsChart() {
  // 声明此组件仅在浏览器中评估；在服务端会主动触发挂起（Suspend）
  use(browser('图表引擎需要使用浏览器 Canvas 及 window 视口宽度'));

  // 挂起之后，此处的逻辑在服务端绝不会执行，仅在客户端安全运行
  const screenWidth = window.innerWidth;
  const token = localStorage.getItem('auth_token');

  return (
    <div className="chart-box">
      <p>当前视口宽度: {screenWidth}px</p>
      <canvas id="data-canvas" width={screenWidth - 40} height="300" />
    </div>
  );
}

步骤 2：在消费父级显式配置 Suspense 边界

use(browser()) 必须依靠外层的 <Suspense> 容器捕获挂起信号。在父组件中提供比例一致的占位骨架：

// app/dashboard/page.jsx
import { Suspense } from 'react';
import AnalyticsChart from '@/components/AnalyticsChart';
import ChartSkeleton from '@/components/ChartSkeleton';

export default function DashboardPage() {
  return (
    <section className="dashboard-panel">
      <h2>实时运行监控</h2>
      {/* 服务端直接输出 ChartSkeleton 的纯 HTML，客户端就绪后优雅替换 */}
      <Suspense fallback=<ChartSkeleton />>
        <AnalyticsChart />
      </Suspense>
    </section>
  );
}

选型决策：什么时候该用哪一个？

这并不意味着 typeof window 已经被完全淘汰。两者有明确的技术边界与应用分工：

1. 坚守使用 typeof window 的场景

• 非 React 通用模块与工具库：例如封装一个双端同构的网络请求 SDK、日志上报器或 safeLocalStorage 读写工具。这些代码与 UI 渲染生命周期完全解耦，不依赖 React 上下文，必须使用原生的 typeof window !== 'undefined'。
• 条件垫片加载：例如判断是否需要动态引入特定 polyfill 或非标准宿主接口。

2. 坚守使用 use(browser()) 的场景

• React 视图层中的客户端组件隔离：凡是需要在服务端渲染时安全展示 Fallback 骨架屏、而在客户端装载重度交互界面的 UI 组件，均应优先使用 use(browser()) 配合 <Suspense>。
• 需要彻底杜绝 Hydration Mismatch 的 SSR 业务页面：如包含复杂第三方 DOM 库（Highcharts、Leaflet 地图、富文本编辑器）的前端项目。

3. 两者都不需要的场景

在用户点击等事件回调函数（Event Handlers）内部，或者在 useEffect 钩子函数内部。因为这些代码段本身就严格保证仅在浏览器客户端事件循环中触发，此时 window 必定存在，直接按需调用对应 API 即可，无需添加任何多余的环境判断。

核心维度总结矩阵

为了便于工程团队在日常代码审查（Code Review）中统一共识，下表对两者的各项核心属性进行了全景归纳：