该渲染由 Shiro API 生成，可能存在排版问题，最佳体验请前往：https://sin6626.me/posts/study&think/step-framework-plate-testing-practices-regression-protection

                        1. *Planning--测试规划*
                        2. *Acquisition--测试资源准备*
                        3. *Measurement--测试执行与评估*

看完了？说点什么呢

该渲染由 Shiro API 生成，可能存在排版问题，最佳体验请前往：https://sin6626.me/posts/study&think/plate-v1-vs-v2-comparison

看完了？说点什么呢

很早就想试试网格布局了，刚好看见了imsyy多年前的项目布局，很喜欢，拿来改成了更加符合现代的技术栈的页面重新审视入口：从独立展示页到门户 最初，shouping 只是一个挂在 /shouping 路由下的独立实验页面，网站原有的内容流主页依然在 /。它的诉求清晰而纯粹：访客进入网站时，首先感知站点的调性与主人的气质，随后再决定是探索主站，还是直达特定工具。 随着视觉打磨与交互逻辑的逐渐成熟，它的角色发生了质的转变——它不再只是一个“附属展示页”，而应当是整个站点的“正门”。我们逐步将完整的站内生态、动态数据看板与沉浸式转场融入其中，最终将它与原首页平滑对调，确立为网站的正式入口（页面灵感来源于(imsyy) 多年前的新手项目）。 布局骨架演进：1:1 对称 左右对称的视觉平衡 页面最外层采用沉浸式全屏纯暗色背景（bg-[#282a30]【NuxtUI默认】），主体内容通过居中容器（max-w-7xl mx-auto）水平垂直居中。 很多页面习惯采用 5:7 或 4:8 的不对称划分，但在以卡片为核心的个人主页中，左右采用 严格的 1:1（grid-cols-1 lg:grid-cols-2）对称平分 才是视觉均衡的最佳解法（原本是想5:7分的，但是效果不好）： 左侧（个人名片区）：包含了悬停微旋转的圆形头像、个性化大字标语、深色毛玻璃一言卡片（古典双引号包裹）、以及社交平台矩阵； 右侧（信息展板与导航区）：横向宽度与左侧卡片严格保持一致，达成几何上的严谨呼应。 右侧 6 栅格体系（grid-cols-6） 右侧需要同时容纳两个信息看板（诗词、时钟天气）与六个快捷导航。我们采用了一个极其工整的 6 栅格体系： 上半部分：2 个信息卡片各占 3 列（sm:col-span-3，$3 + 3 = 6$），等宽平分一行； 下半部分：快捷导航卡片各占 2 列（sm:col-span-2，$2 \times 3 = 6$），一行整齐排布 3 个，两行共 6 个。

拒绝臃肿依赖：挖掘 Nuxt UI Carousel 的手势滑动潜力 当快捷导航项逐渐丰富（分为站内功能集与站外社交/主页），卡片开始超出单屏舒适容量。直觉上很多开发者会立刻 pnpm install swiper 原项目之前就是使用的swiper，根据我的技术栈重新换了个技术，选择优先挖掘当前技术栈（Nuxt UI）的内置能力，如果使用Reka UI作为项目的UI库我可能会使用Swiper/Embla Carousel。 为什么选择 <UCarousel> 而非外部 Swiper？ 零额外依赖与包体积优化：避免为了一组简单的导航引入几十 KB 的 Swiper 运行时与额外的 CSS； 底层基于一流手势引擎：Nuxt UI 的 <UCarousel> 底层直接基于著名的 **embla-carousel-vue**，具备开箱即用的触摸滑动（Touch Swipe）、鼠标按住拖拽（Mouse Drag）、阻尼物理惯性与键盘无障碍切换； 双向数据驱动指示器：我们重构了 navPages 分页结构，并将外部经典的胶囊指示条与轮播事件双向绑定——用户手指或鼠标拖拽滑屏时，指示条通过 @select 实时变宽高亮；点击指示条圆点时，调用 carouselRef.value?.emblaApi?.scrollTo(index) 平滑滚到对应页。 真实世界的动态看板：时钟、天气与水合时区

时钟跳动与 SSR 水合防御： 诗词卡片提供点击循环切换，而时钟卡片则由 dayjs 格式化日期，并结合 @number-flow/vue 呈现机械质感的数字平滑翻滚。 关键边界防御：由于 Nitro 服务端渲染（SSR）通常处于 UTC 时间，而客户端浏览器处于本地时区，时间与星期极易引发水合不一致（Hydration Mismatch）报错。时钟区域严格使用 <ClientOnly> 包裹并提供优雅的骨架屏 fallback，将时间计算收敛在客户端（项目中之前踩过这个坑）。 天气接口与本地缓存解耦： 城市与气温不能靠浏览器预设。我们将其从 UI 中完全抽离至 app/Api/weather.ts； 页面挂载后请求用户地理定位，获得经纬度后向 Open-Meteo 查询实时气温与天气状况； 30分钟缓存机制：天气数据连同坐标与时间戳写入 localStorage，半小时内重进页面优先读取缓存，避免因频繁切换路由向天气服务器重复请求；用户拒绝定位或弱网时，优雅降级为状态提示（没用使用VueQuery是因为觉得在当前接口很少的情况下，完全没有必要引入新的依赖包去增加自己的心智负担和打包后的体积）。 多语言路径安全（useLocalePath）： 站内所有链接使用 @nuxtjs/i18n 的 localePath 统一包装，确保用户不论在中文还是 /en/ 英文环境下点击跳转，多语言上下文都不会被粗暴冲刷。 @click 的边界 在功能趋于完善时，我们经历了两次具有典型工程教育意义的细节排错与探索：

@click.capture 与 @click 的实战真相 在拦截 <NuxtLink> 跳转以注入自定义转场动画时，代码中使用了 @click.capture。 原理剖析：.capture 是 DOM 事件流的“捕获阶段”，意在事件刚进入顶层时先发制人，截胡 <NuxtLink> 的默认路由处理； 实测解惑：实测改成普通的 @click 表现完全一致。这是因为浏览器的“跳转默认行为”必须等待**整个事件流（捕获 $\to$ 目标 $\to$ 冒泡）完全结束**之后才会执行。只要在冒泡阶段调用了 event.preventDefault()，依然能成功截停跳转。在内部没有子元素滥用 stopPropagation 的纯净结构下，使用语义更自然的 @click 即可。 “开门”转场：DOM 快照、卸载感知与无闪帧同步 Visit 按钮、头像以及所有站内导航，绝不仅仅是一次简单的 router.push，而是：首屏沿中间分割线向两侧缓缓撕裂滑开，露出门后准备就绪的主站。 这套复杂的动画被统一收敛在 useEnter.ts 中，背后经历了三层核心攻坚：

1. 视口裁剪与 NumberFlow 快照修复 我们通过 fixed inset-0 z-[9999] 创建全屏遮罩，利用 sourcePage.cloneNode(true) 完整复制当前视口画面，放入两扇各占 50% 宽度的面板容器中，配合 overflow: hidden 精确裁切出左半边和右半边； 时钟消失踩坑：@number-flow/vue 底层是一个封装了 Web Component 原生自定义元素（<number-flow>）的高级组件，shadow DOM，使用cloneNode无法穿透clone，两者不在一个DOM树下，最后是维护了一个H5的自定义属性，让DOM 树在clone的时候读取这个属性渲染页面的（这里应该是最大的坑点了，毕竟是好几年的库了，有坑很正常）。
2. 为什么不能直接在 navigateTo 后面执行动画？（isConnected 与 MutationObserver） await navigateTo(to) 仅仅代表路由切换指令发出了，此时 Vue 还需要异步加载新页面的 Chunk 并执行 setup。 如果直接执行动画，在开发服务器上， 动画首次开始执行的一瞬间，看到的会是旧页面白白停滞了几十毫秒，或者露出一瞬间的白屏，而生产服务器上没有这个问题，但是这也说明了代码不健全的问题； 我们使用 sourcePage.isConnected（浏览器原生 DOM 存在属性）配合 MutationObserver，递归监听 #__nuxt 根节点（{ childList: true, subtree: true }）。 只有当检测到 !sourcePage.isConnected（旧页面彻底从 DOM 树中被拔除、新页面正式就位）的瞬间，才放Promise（resolve()）通过	
3. 消灭白屏闪烁：requestAnimationFrame 即使旧 DOM 拔除了，在浏览器的事件循环机制中，DOM 变化（JS执行）并不等于像素已经画到屏幕上（还需要计算样式、布局与绘制 Paint）。 我们在开门前加入了： 强制让出主线程，等待浏览器把新页面的第一帧稳稳绘制到显卡上，再将门板向左右两侧优雅拉开。至此，白屏、频闪被彻底消除，丝滑度拉满。同时配合 prefers-reduced-motion: reduce，在用户开启减弱动画时自动跳过开门直接秒切，兼顾无障碍体验（requeAnimation在梅花生长动画中也有到了，而动画减弱判断则是在GSAP官方那学到的）。 路由平移与体验闭环 在所有动效、容错与状态机都经过严苛检验后，我们完成了最终的“移花接木”： 根路由对调：原本的 /shouping 正式进驻网站根路径 /，原主站流式页面后移至 /home； 闭环互通：首屏的 Visit 按钮、头像与“主站首页”卡片，通过双开门动画平滑进入 /home；而进入主站后，左上角头像点击可重返 / 门面； 环境验证：Nuxt 预渲染、多语言路径自动转换、SSR 本地构建与全量 TypeScript 类型检查均以 Exit status 0 零警告无缝收官。 昨天晚上加今天一下午完成了这个shouping页并且迁移，今天JOJO飙马野郎更新第二集，看看能不能改个黄金分割的动画😶‍🌫️

该渲染由 Shiro API 生成，可能存在排版问题，最佳体验请前往：https://sin6626.me/notes/10

看完了？说点什么呢

一、问题起因：一次 UI 开发中的严重坐标偏移

今天下午，开发者 sin 在调试其前端 UI 动画合集项目时，测试了之前编写的一个深浅色主题切换按钮。该按钮基于现代浏览器原生的 View Transitions API 打造，预期效果是以鼠标点击位置为圆心，通过 clip-path 裁切出一个正圆水波，丝滑地向全屏扩散展开。

然而在交互实测中，sin 发现了一个无法忽视的视觉瑕疵：水波扩散的圆心并没有对准鼠标的点击位置，而是发生了肉眼可见的大幅空间偏位。

sin 最初编写这个按钮时，参考了开源社区的流行做法（包括 Nuxt 官方示例库中广泛流传的实现）。其核心逻辑是在事件触发后，直接通过 Web Animations API（WAAPI）对根快照伪元素 ::view-transition-new(root) 注入关键帧动画：

// 社区常见的早期写法：利用 TS/JS 计算坐标后直接通过 WAAPI 操纵伪元素
const x = event.clientX
const y = event.clientY
const endRadius = Math.hypot(
  Math.max(x, window.innerWidth - x),
  Math.max(y, window.innerHeight - y)
)

const transition = document.startViewTransition(() => {
  switchTheme()
})

transition.ready.then(() => {
  document.documentElement.animate(
    {
      clipPath: [
        `circle(0px at ${x}px ${y}px)`,
        `circle(${endRadius}px at ${x}px ${y}px)`
      ]
    },
    {
      duration: 600,
      easing: 'cubic-bezier(.76,.32,.29,.99)',
      pseudoElement: '::view-transition-new(root)'
    }
  )
})

这段逻辑在代码组织上极为诱人：坐标获取、半径推导、动画触发全在 TypeScript 函数闭包内闭环，既无需额外维护动态的 CSS class，也省去了清理工作。

但正是这段看似优雅的代码，在高分屏设备上产生了严重的圆心错位。

二、假设推演与 sin 的关键证伪

当 sin 将该问题抛给我（Gemini 3.8 Flash）协助排查时，作为一个大语言模型，我的第一反应也落入了常规前端 Bug 的经验主义推测中。我先后向 sin 提出了几种可能性：

1. 是否页面存在滚动（scrollX / scrollY），导致 clientX/Y 需要补偿？
2. 按钮的外层父级容器是否存在 CSS transform 或 zoom，导致视口局部坐标系发生了缩放或位移？
3. 是否是 Vue 响应式状态更新与 DOM 渲染的时序差异，导致过渡快照截取的时机不对？

面对我的这些推论，sin 并没有盲从，而是凭借敏锐的技术嗅觉，迅速提出了两个极具杀伤力的关键反例，彻底推翻了我最初的方向：

1. 官方标杆项目的同台“翻车”

sin 亲自去访问了 NuxtUI 官方开源模板 —— Emma Thompson - Portfolio Template 的线上演示站。 测试结果令人吃惊：连这个官方模板上的主题切换按钮，在新版浏览器和不同电脑上也同样发生了巨大的圆心偏移！而且在不同的电脑和缩放比下，偏移的距离还不尽相同。 这直接证明了该 Bug 绝非当前项目私有的布局或时序缺陷，而是整个前端社区流传的这套方案本身在现代浏览器底层出现了系统性失效。

2. 纯 CSS 对照组的精准表现

紧接着，sin 指出了项目中另一个决定性的对照组：在当前的组件库中，sin 之前还编写过另一个使用 纯 CSS + CSS 变量 控制 clip-path 的对照按钮。 在完全相同的页面结构、完全相同的事件监听以及完全相同的 (event.clientX, event.clientY) 坐标输入下，该 CSS 按钮在所有设备上均做到了 0 像素偏差的精准对齐，指哪打哪！

sin 的这两记关键反驳，立刻将我们的排查视野从“业务层代码找茬”，直接拉升到了“Chromium 渲染引擎对 WAAPI 伪元素动画的底层解析机理”之上。

三、深层机理：Chromium 渲染管线与 DPR 坐标脱节

顺着 sin 锁定的突破口，我和 sin 共同深入剖析了 Chromium 内核对于 View Transitions 规范的演进历程，终于还原了事情的完整真相。

1. 从扁平快照到独立顶层快照（Snapshot Root）

在 View Transitions API 刚诞生的早期版本（Chrome 111 ~ 125）：

• 伪元素 ::view-transition-new(root) 在 Chromium 内部的处理较为原始，很大程度上被当作根文档视口（Viewport）的一个普通绘制层；
• 当开发者调用 document.documentElement.animate 传入 pseudoElement 时，合成器线程（Compositor）直接将传入的静态像素坐标映射在当前页面的可视视口（Visual Viewport）上，因而早期未暴露出明显的肉眼偏移。

但随着 W3C View Transitions Level 2 规范的正式推进（从 Chrome 126+ 引入跨文档过渡，到 Chrome 130+ 引入 Scoped 容器过渡，直至如今最新的 Chrome 150+ 内核）：

• 规范对快照伪元素树进行了彻底重构，::view-transition 被定义为一个脱离普通文档流、独立挂载在顶级图层（Top Layer）上的快照根容器（Snapshot Root）；
• 为了支持视口缩放与抗锯齿，Blink 渲染引擎为快照伪元素树（::view-transition-group）引入了独立的变换矩阵（Transform Matrix）与栅格化基准表面。

2. WAAPI 伪元素动画与非整数 DPR 的二次畸变

当开发者通过 TypeScript 调用：

document.documentElement.animate(
  { clipPath: `circle(...) at ${x}px ${y}px` },
  { pseudoElement: '::view-transition-new(root)' }
)

这段字符串被直接传递给合成器。然而在现代 Chromium 中，作用在包含独立变换矩阵的快照伪元素层上的 WAAPI 动画，未能正确依据当前的 CSS 布局视口进行逆矩阵换算。

尤其在 Windows 系统常见的高分屏环境（设备像素比 DPR ≠ 1.0，如笔记本常见的 125% 或 150% 缩放）下，快照图层矩阵的物理坐标换算与逻辑像素之间产生了成倍的比例畸变。这完全解释了 sin 所观察到的“每台电脑偏差都不一样”的现象 —— 只要屏幕缩放比或分辨率不同，变换矩阵的偏移倍率就完全不同。

3. 为什么 sin 编写的 CSS 方案完全免疫？

CSS 变量方案的数据流向是： $$\text{点击坐标 (x, y)} \xrightarrow{\text{写入}} \text{:root CSS 自定义变量} \xrightarrow{\text{样式计算}} \text{CSS @keyframes 逐帧求值}$$

由于 CSS 变量直接挂载在 <html>（:root）根节点上，由浏览器的样式计算引擎（Style Engine）在常规文档流的上下文中统一求值。在此处计算出的几何尺寸天生遵循标准 CSS 视口规则并自动适配 DPR 缩放，彻底绕过了合成器层对独立快照伪元素的坐标换算缺陷。

四、工程重构：0 偏差纯单向水波方案落地

在彻底厘清根因之后，sin 对组件提出了更进一步的体验要求：

1. 统一为纯单向水波扩散（Pure Expand）：传统模板在深色切浅色时常采用反向收缩动效（Contract），视觉上极具压迫感。sin 要求无论深切浅还是浅切深，统一以点击位置为圆心向外全屏绽放覆盖。
2. 严禁改动原有参数：完整保留原有的 600ms 动画时长、cubic-bezier(.76, .32, .29, .99) 缓动曲线以及 Math.hypot 外接圆半径覆盖算法。
3. 消除白屏闪烁：在视图过渡回调执行时同步更新 DOM 类名，确保快照捕获即时准确。

我们最终落地的重构代码如下：

1. 脚本逻辑（Vue 3 / TypeScript）

<script setup lang="ts">
const colorMode = useColorMode()

// 计算下一个目标主题
const nextTheme = computed(() => (colorMode.value === 'dark' ? 'light' : 'dark'))

// 同步修改 DOM class，确保 startViewTransition 内部拍摄到目标主题快照
const switchTheme = () => {
  const next = nextTheme.value
  const html = document.documentElement
  html.classList.remove(`${colorMode.value}-mode`)
  html.classList.add(`${next}-mode`)
  colorMode.preference = next
}

const startViewTransition = (event: MouseEvent) => {
  // 降级判断：不支持 View Transitions API 或系统开启了减弱动态效果
  if (!document.startViewTransition || window.matchMedia('(prefers-reduced-motion: reduce)').matches) {
    switchTheme()
    return
  }

  const x = event.clientX
  const y = event.clientY
  const endRadius = Math.hypot(
    Math.max(x, window.innerWidth - x),
    Math.max(y, window.innerHeight - y)
  )

  const root = document.documentElement
  const transitionClass = 'sinui-theme-reveal-expand'

  // 将坐标与半径写入根元素 CSS 变量
  root.style.setProperty('--sinui-theme-transition-x', `${x}px`)
  root.style.setProperty('--sinui-theme-transition-y', `${y}px`)
  root.style.setProperty('--sinui-theme-transition-radius', `${endRadius}px`)
  root.classList.add(transitionClass)

  const transition = document.startViewTransition(() => {
    switchTheme()
  })

  // 过渡结束后清理 CSS 变量与辅助 class
  transition.finished.finally(() => {
    root.classList.remove(transitionClass)
    root.style.removeProperty('--sinui-theme-transition-x')
    root.style.removeProperty('--sinui-theme-transition-y')
    root.style.removeProperty('--sinui-theme-transition-radius')
  })
}
</script>

<template>
  <ClientOnly>
    <UButton
      :aria-label="`Switch to ${nextTheme} mode`"
      :icon="`i-lucide-${nextTheme === 'dark' ? 'sun' : 'moon'}`"
      color="neutral"
      variant="ghost"
      size="sm"
      class="rounded-full"
      @click="startViewTransition"
    />
    <template #fallback>
      <div class="size-4" />
    </template>
  </ClientOnly>
</template>

2. 样式实现（CSS）

/* 禁用默认 cross-fade 动画，防止与 clip-path 产生双重图层叠加混合 */
::view-transition-old(root),
::view-transition-new(root) {
  animation: none;
  mix-blend-mode: normal;
}

/* 旧视图垫在底层，新视图在顶层自点击原点向外扩散覆盖 */
.sinui-theme-reveal-expand::view-transition-old(root) {
  z-index: 1;
}

.sinui-theme-reveal-expand::view-transition-new(root) {
  z-index: 9999;
  clip-path: circle(
    0 at
    var(--sinui-theme-transition-x, 50vw)
    var(--sinui-theme-transition-y, 50vh)
  );
  animation: sinui-theme-reveal-expand 600ms cubic-bezier(.76, .32, .29, .99) both;
}

@keyframes sinui-theme-reveal-expand {
  to {
    clip-path: circle(
      var(--sinui-theme-transition-radius, 150vmax) at
      var(--sinui-theme-transition-x, 50vw)
      var(--sinui-theme-transition-y, 50vh)
    );
  }
}

五、未来展望：View Transitions Level 2 的 types 特性

在讨论过程中，我和 sin 还探讨了 View Transitions Level 2 的演进趋势。对于 Chrome 125+ 及 Safari 18+ 等现代环境，规范原生提供了 types 特性。

利用该特性，开发者未来甚至可以彻底省去在根节点增删 class 的操作：

// Level 2 现代类型声明调用
document.startViewTransition({
  update: switchTheme,
  types: ['theme-expand']
})

CSS 直接配合原生伪类匹配：

html:active-view-transition-type(theme-expand)::view-transition-new(root) {
  z-index: 9999;
  clip-path: circle(0 at var(--sinui-theme-transition-x) var(--sinui-theme-transition-y));
  animation: sinui-theme-reveal-expand 600ms cubic-bezier(.76, .32, .29, .99) both;
}

过渡类型会在动画周期内由浏览器原生激活与注销，实现更加纯粹解耦的状态控制。

六、结对复盘：人机协作中的思考

这次我与 sin 共同排查并解决问题的全过程，为我们留下了两点深刻的工程启示：

1. 破除对权威开源模板的盲信，善用对照实验：
   像 Emma Thompson 这样NuxtUI的官方的模板，其代码编写于 API 刚刚诞生之初。当底层规范和浏览器引擎发生重构后，曾经的“最佳实践”往往会演变成“技术暗礁”。在排查时，sin 没有盲目纠结于“是不是我代码写错了”，而是通过拉取官方在线环境交叉比对，并利用自身编写的 CSS 对照组快速切断无效假设，这是本次能够迅速击中内核痛点的关键所在。
2. 合理的工程职责边界划分：
   JavaScript / TypeScript 应当聚焦于业务状态管理与事件输入，而图层裁切、补间动画以及复杂的几何计算，交给 CSS 样式引擎处理往往更加健壮。“JS 提取变量暴露给 Custom Properties，CSS 原生消费变量驱动 Keyframes”，不仅亲和 GPU 硬件加速，更能天然获得现代浏览器对多倍率屏幕（DPR）的精准适配能力。

前言：一直以来，Vue 都是我的主力前端框架。从模板语法、响应式数据到组合式 API，Vue 的“开箱即用”和“保姆级体验”伴随我完成了许多项目。最近，我系统地学习了小满老师的 React Docs 文档，将 React 作为我的第二门前端框架正式纳入口袋。

虽然目前我刚刚学完整个教程、还没有在实际商业项目中完整踩过实战的坑，但这套体系化学习下来，我最大的感受就是：React 和 Vue 的底层世界观完全不同。

下面对照这份 React 文档的知识脉络（基础语法、编译工具、底层原理、组件体系、CSS 方案、Hooks 全家桶、路由与状态管理），结合我熟悉的 Vue，写下这份初学者视角的框架对比与心得笔记。

1. 入门与语法：模板指令 vs “一切皆是 JS”

打开文档的第一章，就是 TSX（JSX）语法。对于习惯了 Vue 模板语法的开发者来说，这是第一道冲击。

学习感受：

• Vue 的感受是“规整”：Vue 给开发者设计好了各种指令（v-if, v-for, v-model），模板结构清晰，HTML 该长什么样就是什么样。
• React 的感受是“自由”：TSX 根本不是模板，它本质上就是 JavaScript 语法扩展。不用记框架自创的指令语法，只要 JS 基础好，就可以随意用 if/else、map、filter 来组装 UI。

2. 构建与编译工具：Babel / SWC vs Vue SFC Compiler

文档在“工具篇”特意讲解了 Babel 与 SWC。

• React 的转译本质：我们写的 <div className="box">Hello</div>，经由 Babel 或 SWC 转译后，本质上是变成 React.createElement('div', { className: 'box' }, 'Hello')（或者新的 _jsx('div', ...)）。
• 对比 Vue：Vue 的核心是 SFC（单文件组件 .vue），由 @vitejs/plugin-vue 解析，将 <template> 编译为高效的 render 函数，并将 <script> 和 <style> 分离处理。

学习感受：

通过文档手写 Babel/SWC 转译示例后我才明白：React 的组件真的就是一个返回虚拟 DOM 对象的纯 JS 函数，它没有 Vue SFC 那么强的结构专属感。

3. 核心原理篇：不可逆的时间切片与细粒度响应式

文档中关于 VDOM、Fiber、Diff 以及 requestIdleCallback 的章节是我读得最过瘾、也最烧脑的部分。

① Fiber 架构与双缓存机制

• React 的痛点与解法：早期的 React 递归遍历 VDOM 树，如果组件树太深就会长期霸占主线程导致页面掉帧卡顿。于是 React 16 彻底重构为 Fiber 架构，把树状结构变成了链表结构，借助浏览器空闲调度（类似 requestIdleCallback）实现可中断、可恢复的异步更新（时间切片）。并通过“当前树 (current)”与“工作树 (workInProgress)”双缓存交替来提高渲染稳定性。
• Vue 的解法（靶向更新）：Vue 根本不需要 Fiber 这种复杂的时间切片！因为 Vue 拥有基于 Proxy 的精准依赖收集。Vue 在编译时做了大量静态标记（PatchFlag、静态提升），数据变化时，直接精准定位到对应的组件或具体 DOM 节点进行打补丁，更新开销极小。

② Diff 算法差异

• React Diff：同层比较，仅支持向右移动单向比较，若 key 匹配但位置靠前，可能会引发多余的移动操作。
• Vue Diff：Vue 2 采用双端 Diff（头头、尾尾、头尾交叉对比），Vue 3 采用基于最长递增子序列的快速 Diff，在 DOM 移动次数的优化上更加极致。

4. 组件体系：单向流动的严谨与灵活

文档中的组件篇涵盖了组件通信、受控组件、Portal、Suspense 和 HOC（高阶组件）。

① 受控组件 vs v-model

这是初学 React 时最容易手忙脚乱的地方：

• Vue：一个 v-model="text" 搞定双向绑定。
• React：必须显式声明为受控组件：

  <input value={text} onChange={(e) => setText(e.target.value)} />

② 插槽 vs children & Render Props

• Vue：拥有极其完善的插槽系统（默认插槽、具名插槽 <template #header>、作用域插槽）。
• React：默认内容直接通过 props.children 获取；如果需要作用域插槽的效果，直接传一个函数即可（Render Props 模式：props.render(data)），纯 JS 函数传参，简单直接。

③ 传送组件与异步组件

• 传送组件：React 的 createPortal(JSX, domNode) 对标 Vue 的 <Teleport to="body">。
• 异步加载：React 的 lazy(() => import(...)) + <Suspense fallback={<Loading />} /> 对标 Vue 的 defineAsyncComponent + <Suspense> (但是这部分我在Vue里面没怎么用过...)。

④ 高阶组件 (HOC)

React 拥有丰富的高阶组件文化（接收组件并返回增强后的新组件），而 Vue 社区在进入 Vue 3 后基本统一推崇 Composition API，极少使用 HOC, React在更多的Hooks支持下, HOC的使用场景也被大大压缩, 平时开发听小满说根本用不到。

5. CSS 方案：自由探索 vs 开箱即用

在 Vue 里，我们最习惯的写法是：

<style scoped>
.title { color: red; }
</style>

scoped 属性通过 PostCSS 自动给 DOM 添加 data-v-xxx 属性选择器，干净又好用。

而在 React 文档中，CSS 方案是一场“百家争鸣”：

1. CSS Modules：文件命名为 index.module.css，像对象一样 import styles from './index.module.css'，通过 className={styles.title} 调用，生成哈希类名隔离, 说到底是没有Vue那种scoped隔离的痛。

2. CSS-in-JS（如 styled-components / emotion）：把样式直接作为组件来写, Ant Design就是用的这种方式写的样式。
3. Tailwind CSS：原子化 CSS，文档里重点推荐，由于写在 className 里很自然，在 React 社区极为流行, 当然在Vue的圈子里面也极为的流行, 说到底就是极为的流行。

6. 核心重头戏：React Hooks 全家桶 vs Vue 组合式 API

读完整份文档，Hooks 是篇幅最大、也是和 Vue 3 Composition API 思想碰撞最激烈的部分。

① useState vs ref / reactive

• Vue：数据是“可变响应式代理”。

  const count = ref(0)
  count.value++ // 直接修改，Proxy 自动捕获并派发更新

• React：强调不可变数据（Immutable）（很傻感觉，DX很不好，得用第三方useImmer去加强DX）。

  const [count, setCount] = useState(0)
  setCount(count + 1) // 必须显式调用 setter，不能直接 count = 1

② useEffect vs watch / watchEffect / 生命周期

在 Vue 中，挂载、卸载、监听是各司其职的（onMounted、onUnmounted、watch）。
而在 React 中，文档把所有的“副作用”都归拢到了 useEffect 中：

• 依赖项传 []：相当于 onMounted，返回的清理函数相当于 onUnmounted。
• 依赖项传 [count]：相当于 watch(count, ...)。
• 文档还介绍了更细分的 useLayoutEffect（DOM 变更后、浏览器绘制前同步执行，防闪烁）以及 useInsertionEffect（专为 CSS-in-JS 插入样式设计）。

③ useMemo & useCallback vs computed（最大的心智负担差异！）

这是我认为 Vue 转 React 最需要适应的核心区别：

• 在 Vue 3 中：组件的 <script setup> 只在初始化时执行一次。computed 自动收集依赖，数据变了才重新计算，完全不需要手动管理函数的引用。
• 在 React 中：每次状态变化，整个函数组件就会从头到尾重新执行一遍！
• 组件内的普通函数每次渲染都会重新声明新的引用，导致传递给子组件时引发子组件无意义的重渲染；
• 因此必须显式使用 useCallback 缓存函数引用，使用 useMemo 缓存计算密集型结果！

好在后面的Next中已经可以开启Rect Compiler减少这种心智负担, 不然真的会死人的😢

④ useRef 的双重身份

在 Vue 中 ref 既用来做响应式数据，又用来绑定 DOM。
在 React 中：

1. 获取 DOM 节点：<div ref={domRef} />；
2. 保存跨渲染周期的可变数据：useRef(initialValue) 改变 .current 不会触发组件重新渲染，.current可以得到绑定的DOM的值

⑤ 并发特性 Hooks（useTransition & useDeferredValue）

文档中还深入到了 React 18 的并发特性：

• useTransition：把某些不紧急的状态更新（如复杂的列表过滤）标记为低优先级过渡任务，防止输入框打字卡顿。
• useDeferredValue：延迟派生某个值的更新。
  这展示了 React 面对重型计算和交互优先级调度时的强悍能力。

7. 路由与全局状态管理：React Router 与 Zustand

① 路由篇：React Router v7 vs Vue Router

• Vue Router：中心化路由配置，配合内置的 <router-view>，导航守卫（beforeEach）非常直观。
• React Router (v7)：有loader和action两个路由的行为, 这个是跟Vue有很大区别的地方, 可以在页面上要Get请求获取数据的地方提前在路由的loader中执行, 页面中需要执行Post提交表单的地方执行路由action里面的逻辑, 提交表单数据, 然后回到页面还能自动执行一次loader获取一次新的数据, 这一点让开发的体感很好, 还有各种Hooks useNavigate(), useParams(), useLoaderData(), useActionData()。
• React Router还有很多模式, 但是实际上感觉还是使用跟Vue一样 的数据路由模式更好理解。

② 状态管理篇：Zustand vs Pinia

文档在全局状态管理中选择了极其轻巧优雅的 Zustand，而不是笨重的传统 Redux：

import { create } from 'zustand'

const useStore = create((set) => ({
  bears: 0,
  increase: () => set((state) => ({ bears: state.bears + 1 })),
}))

• 对比 Vue 的 Pinia，两者的开发体验惊人地相似：都摒弃了 Mutation 的概念，体积轻巧，支持直接解构 Hook 使用。
• 但 Zustand 在内部依然严格遵循 React 的不可变合并思想，写起来非常纯粹。
• Zustand 还有自定义各种middleware和官方推荐的第三方的middleware就比如Immer, 这个就很好使用, 能不用管React什么傻x的不可变数据原则, 虽然底层还是保留了这个原则。

总结：我的学习感想

学完这整套 React 文档，如果用一句话总结两者的区别：

Vue 像一辆配置自动档位的车：响应式自动追踪、模板指令丰富、Scoped CSS 开箱即用，框架替你处理好了绝大多数优化细节，上手平滑、开发体验极度舒适。 就很自动， 而且三剑客不分离，代码美观易懂 ，新手上手很快，跟着官方走准没错，生态方面差一点。

React 则像一辆纯手动挡的车：没有魔法，纯粹靠原汁原味的 JavaScript 驱动。它的单向数据流、不可变思想和 Fiber 架构非常严谨，但也正因如此，很多优化得自己去调用Hooks。三剑客合家，代码不美观。但是React的生态丰富， 社区热情度更高，有很多UI库和Hooks库，人人都可以处理React麻烦的点，欣欣向荣。

作为刚刚学完理论知识、尚未经历大型项目实战的前端学习者，我不知道这些说的对不对，但是这就是我个人的感受。学习React我认为在如今是必须，无论是你为了ReactNative的跨端带来的便利，还是为了阅读更多React，Next的优秀项目，React都是作为前端的必需品。在Ai时代下，学习一个框架变得更加的简单，不懂的知识能问Ai快速的获取，代码也从一定要能写出来，更加的倾向于能看懂，知道逻辑，技术栈的选择感觉也更偏向于Ai能不能把这个技术的代码给写好，毕竟现在都是Ai写代码。

该渲染由 Shiro API 生成，可能存在排版问题，最佳体验请前往：https://sin6626.me/notes/9

看完了？说点什么呢

踩坑日记, 由Ai总结 ---- 踩过的坑才印象深刻, 才能真正记住

坑 1：localhost 能通，127.0.0.1 却连不上（导致公网 502）

1. 现象与排查

本地 Vite 服务运行在 3200 端口，浏览器访问 http://localhost:3200 正常，但执行 curl.exe http://127.0.0.1:3200 却报错 Failed to connect: Could not connect to server。

检查端口监听状态：

powershellnetstat -ano | findstr :3200
# 输出：TCP    [::1]:3200    LISTENING

2. 根因分析

• localhost：现代系统与 Node.js 17+ 默认优先解析为 IPv6 的 [::1]。
• 127.0.0.1：是 IPv4 回环地址。Vite 默认只绑定了 IPv6 [::1]，IPv4 根本没有服务监听。
• 连锁反应：frpc.toml 中配置了 localIP = "127.0.0.1"，FRP 转发公网请求到本地 127.0.0.1:3200 被拒，对外直接表现为 HTTP 502。

3. 解决办法

修改 vite.config.ts，显式配置 host: '0.0.0.0'（监听全网卡双栈）：

tsexport default defineConfig({
  server: {
    host: '0.0.0.0',
    port: 3200,
  },
})

坑 2：修改了 frps.toml，端口却未生效

1. 现象与根因

服务端修改配置 bindPort = 7100 后执行了 systemctl start frps，客户端仍报错 session shutdown。

• 原因：systemctl start 只负责启动未运行的服务。frps 已经在后台常驻运行了数月，执行 start 不会重新加载配置。

2. 解决办法

bashsudo systemctl restart frps       # 重启以加载新配置
ss -lntp | grep 7100              # 确认 7100 端口已处于 LISTEN 状态

坑 3：[[proxies]] 代理配置名称重复

1. 现象与根因

frpc.toml 中配置了多个代理节，但 name 字段使用了相同名称：

toml# ❌ 错误：两处代理 name 重复
[[proxies]]
name = "mqtt_remote"
localPort = 1883
remotePort = 6183
[[proxies]]
name = "mqtt_remote"
localPort = 3200
remotePort = 6001

客户端日志报错：start error: proxy [mqtt_remote] already exists。在 FRP 中，name 是每个 Proxy 唯一的标识 ID。

2. 解决办法

确保每个代理条目的 name 全局唯一：

toml# ✅ 正确配置
[[proxies]]
name = "mqtt_remote"
type = "tcp"
localIP = "127.0.0.1"
localPort = 1883
remotePort = 6183
[[proxies]]
name = "web_3200"
type = "tcp"
localIP = "127.0.0.1"
localPort = 3200
remotePort = 6001

🛠️ 标准排查链路速查

text公网请求 (38.95.74.213:6001) ──> frps 服务端 ──> frpc 客户端 ──> 本地服务 (127.0.0.1:3200)

遇到穿透异常，建议按 “服务端 -> 本地服务 -> 网络连通 -> 日志” 的四步链路排查：

1. 检查服务端监听：ss -lntp | grep frps（确认 7100 通信端口与映射端口处于 LISTEN 状态）。
2. 测试本地服务可用性：powershellTest-NetConnection 127.0.0.1 -Port 3200 Test-NetConnection 127.0.0.1 -Port 1883(如果本地 IPv4 都不通，FRP 必定返回 502，先改 Vite 0.0.0.0)
3. 测试公网端口连通：powershellTest-NetConnection 38.95.74.213 -Port 6001
4. 定位客户端/服务端日志：查看 frpc.log 或 frps.log 是否存在 proxy already exists 或认证报错。

📌 核心经验总结

1. localhost ≠ 127.0.0.1：遇连接异常先跑 netstat -ano | findstr :端口 确认是 [::1] 还是 127.0.0.1 / 0.0.0.0。
2. 改配置务必 restart：systemctl start 不会重载正在运行的进程。
3. [[proxies]] 必须命名唯一：name 是 FRP 的唯一代理 ID。

该渲染由 Shiro API 生成，可能存在排版问题，最佳体验请前往：https://sin6626.me/notes/8

看完了？说点什么呢

该渲染由 Shiro API 生成，可能存在排版问题，最佳体验请前往：https://sin6626.me/notes/7

看完了？说点什么呢