<![CDATA[葉は静かに落ちる]]>https://sin6626.mehttps://sin6626.mehttps://sin6626.me/Devil.ico葉は静かに落ちるhttps://sin6626.meShiro (https://github.com/Innei/Shiro)Sun, 20 Sep 2026 18:50:58 GMTSun, 20 Sep 2026 18:50:58 GMT<![CDATA[出租屋的最后一晚]]>
该渲染由 Shiro API 生成，可能存在排版问题，最佳体验请前往：https://sin6626.me/notes/10

|&#32;两个月的暑假转瞬而过, 今天是我在出租屋的最后一晚, 记录总结下这两个月做的事情

刚进出租屋立Flag都实现了吗？

Flag关联文章是是这个社会篇: 第一天的实习 - 葉は静かに落ちる。刚刚住进出租屋实习的时候给自己立了三个搬出出租屋时候要完成的Flag，原本是打算实习三个月的，但是最后却只有两个月，导致完成Flag时间很紧张，不过好在最后没有辜负自己的期望，完成了。

image.png

关联文章

  1. NestJS学习 - 葉は静かに落ちる
  2. React学习心得分享: React 对比 Vue - 葉は静かに落ちる

LeetCode截图：

260489ad7aaef46be561a4d39b6680b4.png

image.png

Nest和React都还没有正式的去做项目，项目大部分还是Vue和Nuxt的，毕竟时间已经不够了，不过我后面会去做的，Nest和React（Next也学完了，不过没发文）我一直都认为是一个非常好的技术，有非常优秀的开源项目，学习的资源很多。慢慢来吧，一个人慢慢走，累了就歇歇，然后继续走。

更多的技术

2个月时间我并不是只把三个Flag主线任务给完成了，还做完了很多的支线任务。有很多很多，简单例举下。

更加绑定了Nuxt生态，如NuxtUI，NuxtContent，NuxtStudio，NuxtAuth，Nuxt18n；动画方面也研读了很多大佬的项目，学到了很多与动画有关的技术或者是CSS属性，对于动画的实现有更加清晰的认知，有用css的clip-path做画面的切割，用stroke-dasharray + stroke-dashoffset做SVG简笔动画，用Motion做更加通用的动画，善用spring预设，Motion的Layout和LayoutId也是一把好手，用GASP可以做命令式更加复杂的动画，配合MorphSVG，ScrollTrigger，SplitText等插件实现更多动画，number-flow可以做钟表般富有机械感，精细的时间转动动画；还有Web 3D，OpenGL，WebGL，Three实现3D效果，使用Glsl做Shader编程，用GPU加速渲染等。大部分的技术都是看别人项目源码，看官方文档，问Ai学习的，毕竟大部分的时间要上班，上班也不能看视频学习。

为此我开了一个项目去收藏记录我学到的UI和动画技术，项目是纯静态的，还没加入后端，最近其实我还去实现一个IM系统，那时候会加上的吧。ui-animation-collection.vercel.app/animation/interactive-icon-morph。项目感觉我个人认为最惊艳的地方是音频3D可视化，忘记说了，项目没有部署在自己的服务器上，是在Vercel上，得开魔法网络才能进去看。

image.png

其他所获

给GSAP官方文档提出了一个建议，被官方采纳了，有关文章是这个gsap官方文档的更新和Svg线条动画的探索 - 葉は静かに落ちる

image.png

那时候感觉很高兴，很激动，逢人就说，哈哈哈哈哈。

公司所获

这次实习是一个很小的公司，才注册4年不到，注册资50w，除去老板一共5个正式人员，但是在公司也收获不少。第一次接触了Android开发相关的知识（虽然不是真正做Android开发），用到了很多原生Android的模块，Accessbility无障碍，NotificationServer做控制栏监听，还有Content去可以读取短信数据库什么的。也懂了很多项目调试的方式，CICD部署项目，前后端兄弟们应该如何联调，一个好的后端应该具备什么样的品质（被后端文档折磨过的感悟）。还有就是坚定了我放弃Uniapp这个技术栈的决心，Uniapp如果是写小程序可以用下，但是App（也是我转向ReactNative的原因）我是真的不想用了，DX拉完了，第一次觉得有Ai了开发还是如此的痛苦。

还认识了公司里的同事们，感觉跟同行的人说话更加轻松愉快。

不过听说我前脚刚走，公司好像出了问题，把三个正式工给开了，好像是项目没做好，要打官司，不过具体的并不清楚，信息也是听走的晚的人说的，也希望公司能挺过难关吧，感觉老板人和技术人还是很不错的。

下一步计划

打物联网的比赛，赛后继续消化Innei24年的项目，尝试今年跟大四的抢下秋招，春招的实习岗位，学习ReactNative，继续学习Nest，学习更多的设计，看了月之暗面的招聘信息，打算补上在移动端的技术短板，目标是Android原生（虽然听别人已死...），持续算法学习，我马上大三上，还有一年的时间，还是有可能在明年的秋招以2K的LeetCode刷题量进场的，群友也是推荐我继续刷算法，那再刷一年。还有就是要往Agent方面靠近了，已经盯上了一个技术了，洛鱼的用Vue组件形式未作Agent信息载体的技术。

继续努力吧，累了就歇歇，然后继续走下去，当第一颗卫星飞向大气层外，我们便以为自己终有一日会征服宇宙。我靠，忘记说日语方面了，不管了， 算了算了

看完了？说点什么呢

]]>https://sin6626.me/notes/10https://sin6626.me/notes/10Fri, 04 Sep 2026 16:05:38 GMT<![CDATA[基于 View Transitions 的主题切换水波动画圆心偏移排查与重构]]>
该渲染由 Shiro API 生成，可能存在排版问题，最佳体验请前往：https://sin6626.me/posts/technology/view-transitions-api-theme-switch-animation-origin-analysis

一、问题起因：一次 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）的精准适配能力。

看完了？说点什么呢

]]>https://sin6626.me/posts/technology/view-transitions-api-theme-switch-animation-origin-analysishttps://sin6626.me/posts/technology/view-transitions-api-theme-switch-animation-origin-analysisFri, 04 Sep 2026 14:24:28 GMT<![CDATA[React学习心得分享: React 对比 Vue]]>
该渲染由 Shiro API 生成，可能存在排版问题，最佳体验请前往：https://sin6626.me/posts/study&think/react-vs-vue-learning-experience

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

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

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

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

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

业务场景Vue (Template 语法糖)React (TSX / JS 表达式)体验感受
数据插值{{ message }}{message}React 用单大括号，里面可以写任意合法的 JS 表达式。
条件渲染v-if="flag" / v-elseflag ? <A /> : <B /> 或 flag && <A />Vue 是指令化思维；React 完全靠原生 JS 的三元运算符和短路求值。
列表渲染v-for="item in list" :key="item.id"list.map(item => <li key={item.id}>{item.name}</li>)React 没有特定指令，就是原生数组的 .map()。
事件绑定@click="handleClick"onClick={handleClick}驼峰命名，传函数引用。
类名绑定:class="{ active: isActive }"className={isActive ? 'active' : ''}React 中 class 是 JS 关键字，必须写 className；for 需写成 htmlFor。

学习感受：

  • 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 以及&#32;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写代码。

看完了？说点什么呢

]]>https://sin6626.me/posts/study&think/react-vs-vue-learning-experiencehttps://sin6626.me/posts/study&think/react-vs-vue-learning-experienceTue, 01 Sep 2026 14:20:43 GMT<![CDATA[前端已死&世事无常]]>
该渲染由 Shiro API 生成，可能存在排版问题，最佳体验请前往：https://sin6626.me/notes/9

上班疲倦，前端已死。为什么世事无常，明明昨日还在一起工作，一起吃饭，一起讨论，一起玩乐的人，今天却要离开公司

纯写日记，把我的感受写下来

我很难受这一周，公司很压抑，工作压力很大，心情很不好，更加难受复杂的是，又有一个实习生同事要走了，是公司想让他走，这让我更加的难受。原本的四人，然后三人，到了现在的两人，昨日还见的人，次日就再也见不到。

这次走的后端兄弟是跟我聊天最多的人，他叫hanirz，是我在公司第一个见到的人，我当初第一天上班，没有录制指纹，早早到的了公司了门口，但是进不去。他是随后到了公司，是我见到的第一个公司的同事，他开了门，我们交谈，聊着公司怎么样，谁谁谁是怎么样的，我的座位在哪，还告诉了我WiFi密码。我记得那天，是周五，上完那天就周末放假，第一天上班，Mentor好像也没想让我干活，就让我去看UniApp的文档，把文档都过一遍。我就看了一上午文档。中午12点吃饭，我不知道吃什么，只是记得技术群里面的PP告诉过我，中午吃饭跟同事们一起去吃。这时候hanirz突然拍我的肩膀说要不要一起去吃饭，我很高兴，就跟一起实习生们去吃饭了，一共四人，他们都是大三的。

午饭后，我跟他们说要不要先不要上去，反正上去也是睡觉，干脆在下面多聊天会，都介绍认识下，那时候都还是很热血的实习生，第一次实习，都在讨论Java，项目又是怎么怎么的，哪里有怎么了。hanirz他就在抱怨，Mentor给了他一个项目，让他去测试项目流程，有没有bug什么的，然后去修，但是他是一个Java后端，他不懂前端的代码，不知道前端传递的参数是什么，怎么看，说他搞得他很难受，于是我说让我去搞那个项目的前端，配合他去测试和修复bug，他也很高兴，于是我们就第一次搭把手配合了起来。后面随着越来越熟络，感觉四人的感情也越来越好，很好的同事关系。

前端有涯

中途有个同为前端实习生，做他那个项目天天加班，并且客户要求很多，小而多，还要跟同为项目经理的后端去对接口，有时候晚上7,8点了还要改页面，还要打包给客户看。有人晚上项目经理diao了，然后回了一句，第二天就提出了离职，他说他受不了了。

image.png

今天还有一个正式工的前端女生，也被diao了，被说得还掉眼泪了，她是一个工期很长的项目快要到交付的时候还有很多功能没有实现，而且页面上的图还不是真实的切图而是蓝湖上面的网络图片。说实话这点确实是她的问题，而且是很愚蠢的问题。然后晚上她回去还要在改页面，核对接口，说实话真的心痛，看着前端兄弟们都是当牛做马，我很痛苦。我自己和后端联调的时候，后端调用接口不自己去Postman，ApiFox调用调试，让前端自己调用，让前端把接口返回发出来，Api文档信息不够，Ai自己猜接口返回值含义，然后从上级那听着客户要求，让Ai去改页面，写着屎山代码。

我看着他们天天改页面，然后为了项目还要天天加班，我心很累，虽然网络上可能说做互联网这一行，加班是常态，但是我认识的学前端的人都不加班，只有一个做上海做芯片的自愿加班，因为加班费很多。我向往的前端是一个很有创意力的职业，AnthonyFu的耗牛毛地图，面向技术人员做PPT的slidev和各种各样的动画效果；Innei的MixSpace生态，Yohaku和Shiro；青山老哥的VueMini；洛鱼和NeKo等人的airi。在我看来前端充满着各种创意，还有对于美的感受，所以我看见有前端兄弟为了改页面，为了调接口而加班到很晚，让我很难过，很窒息，这还是我们行业吗，为什么前端天天就是用着Ai去改页面，跟着设计稿拿切图贴在页面上，改着客户无理取闹的要求，还要被老板压力。网络上都在说前端已死，没工作的时候我会理解为Ai很强大了，能够代替前端直接完成页面。但是实际上呢，公司使用Uniapp，Ai对Uni不够熟悉，开发工具链没有Web完善，Ai难以调试，有的前端兄弟天天加班，被老板压力，真正的前端已死，我想我可能才明白。不是说前端已经可以被Ai替代，而是小前端的未来让人绝望的想死，难怪之前技术群里面有人让我不要去学前端，真的坐牢。

世事难料

说回hanirz，其实我并不知道公司想让他走明确的原因和导火索，根据他说，是因为他有要5天完成的项目，他第一天为了不浪费即将刷新的codex的额度，于是开5.6 Sol 写了四个小时代码，然后加上第二天的代码，分几次提交100多个文件。然后就被经理叫过去说了他写的代码怎么怎么样，说多做了什么什么业务，什么错误枚举类放在了Service层什么的，我并是不很了解。在我眼里只是，我下午在看着VueQuery，做着手里的活，hanirz被经理喊过去了一次，然后下午下班要去回去的时候，突然hanirz跟我说自己要走。那时候我还以为他开玩笑呢，问了他好几遍，回去的时候他们就把下午发生的事情都说了出来。他下午还被Mentor喊过去了，问他要不要，跟他说了工资的事情。

谁能想到，昨天还一起吃饭，一起玩乐，说好了10月份一起走的人，今天突然告诉你他要走了。在压力最大的时候，不是被压力走了，而是公司暗示让你走，苦涩复杂。我第一次实习，在公司第一个认识的人，玩的好的朋友，就这样不给我反应的时间下走了。下班后我们三人去吃了一餐散伙饭，饭桌上说我们说了很多很多事，但是都没什么用。

合影.png

hanirz的走其实让我也不得不思考最近的打算，原本是打算10月份走，上三个月班，抽空学习，完成自己上班前立的三个Flag，确实自己这段时间抽空学了很多，NuxtUI，NuxtContent，i18n，Nuxt Studio，Iconify图标，精进Tailwind，Gsap，MorphSVG插件，Motion-V，View Transition API，ClipPath属性 stroke-dasharray + stroke-dashoffset构造CVG简笔画，Canvas，Web Audio Api，Threejs，WebGL，OpenGL，Shader，GLSL，VueQuery，Vercel使用，也做出了自己喜欢的东西，公司也让我学到了很多Android方面的知识，NotificationListenerService通知栏监听，ContentResolver去读取系统短信数据库，还有很多UniApp中的小坑小点小细节。hanirz的离开让我觉得我可能也不一定能在这里待到10月了，我之前立的三个Flag可能还真的无法完成。

前端让我又爱又恨，hanirz的离开我伤心复杂，但是对他来说可能也是一种解脱，我还有一年的时间，还有机会，稳住节奏，向着自己的热爱前进，厚积而薄发，谋定而后动

看完了？说点什么呢

]]>https://sin6626.me/notes/9https://sin6626.me/notes/9Fri, 21 Aug 2026 16:50:21 GMT<![CDATA[【FRP + Vite 踩坑记录】localhost 能访问，公网却 502？排查 IPv6、服务重载与代理重名]]>
该渲染由 Shiro API 生成，可能存在排版问题，最佳体验请前往：https://sin6626.me/posts/crash/frp-vite-localhost-502-public-ipv6-reload-proxy

踩坑日记, 由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。
访问方式对应协议监听状态访问结果
http://localhost:3200优先 IPv6 (::1)已监听✅ 正常
http://[::1]:3200纯 IPv6 回环已监听✅ 正常
http://127.0.0.1:3200纯 IPv4 回环未监听❌ 连接被拒

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&#160;0.0.0.0)
  3. 测试公网端口连通：powershellTest-NetConnection 38.95.74.213 -Port 6001
  4. 定位客户端/服务端日志：查看 frpc.log 或 frps.log 是否存在 proxy already exists 或认证报错。

📌 核心经验总结

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

看完了？说点什么呢

]]>https://sin6626.me/posts/crash/frp-vite-localhost-502-public-ipv6-reload-proxyhttps://sin6626.me/posts/crash/frp-vite-localhost-502-public-ipv6-reload-proxyTue, 18 Aug 2026 14:40:34 GMT<![CDATA[塞翁失马，焉知非福]]>
该渲染由 Shiro API 生成，可能存在排版问题，最佳体验请前往：https://sin6626.me/notes/8

这两天发生的事情让我深刻体会到了这句谚语 ---- “塞翁失马，焉知非福”

8月12号

隔壁Agent交流群里面有人在抱怨codex速度太慢了，额度烧得太快了，然后就考虑要投奔Grok。他有一个比价的网站，里面有很多的codex和Grok的代充。于是他在网站上找到一家店铺，花费330R拿下Grok Heavy（一个月300美刀）的三个月的订阅。。。

那会也是刚出了Grok的imagine2，而且听他说生图能力可以比肩上GPT-Image-2，中文的排版能力也不差。加上前一阵子出的Grok4.5和Grok Build， 这下可以说Grok真的能够上桌了。而且Grok 在11号还推出了他们的GrokBot（这个用起来体感真的好），听说之前是xAi内部人员使用的。现在Grok Heavy可以直接使用GrokBot，并且还会送一个月的Cursor Ultra（一个月200美刀），简直无敌！！！。而这位群友仅仅只花了330R， 我心动了🩷，学着他用了黑充。第二天就后悔了。

第二天

第一天晚上我就开始捣鼓起来了这些新的Ai工具（对我而言）， 下载了Cursor，GrokBuild， Grok App， GrokBot。

第二天到公司我就很高兴跟实习生同事们说这些工具的事情，那可是顶档的Cursor，顶档的Grok，Cursor能用fable 5，Grok Build 能一直开 Grok 4.6 High（凌晨出了4.6）， 额度都不带掉的。加上公司老板们都没喊我干活，我能一直研究这些新工具的使用，尤其是GrokBot，用起来真的顶。相当于0配置的Hermes，并且产品有顶级前端UI，就这个UI，那位前端看了能不爱？于是我一上午就都在使用GrokBot。

image.png

但是呢，中午醒来我直接傻眼了，隔壁群里面黑充GrokHeavy的兄弟的订阅掉了！我也赶紧打开电脑看下我的Grok订阅，果不其然也掉了。24小时都没到，黑充都掉了，只有小部分幸存者。我的330大洋啊！一天都没到，直接掉，黑充再也不充了！

但是也有一个好消息，到目前为止Cursor Ultra没有掉，而且我的GrokBot也能跑。（希望明天还能跑。。。）

Follow GrokBot

GrokBot这个产品真的是我从今年的opencode开始，使用过最好的Ai工具了，真的惊艳到我了，体感无敌好。一句话形容：“0配置，开箱即用的SuperHermes”。GrokBot中的每个Bot都共享一台云电脑，但是每个Bot都有一个电脑的界面（大概，没有专门去连去看），电脑里面初始只有三个东西，一个谷歌浏览器，一个文件管理器，一个终端，你能连接直接连接他们电脑去看，去使用（类比ToDesk）

image.png

他的产品就像是一个微信的聊天界面，你的联系人就是你创建的各个Bot，既然像个微信，那么肯定是有群聊功能，也可以像微信一样使用@符号去专门的指定Bot。你只需要在群里面说话，说一个大概要做的事情，分配好任务的Bot们就会去他们的电脑里面去执行任务。并且他们能像同事一样群内互相@通信，共享资料，同事之前私聊也可。例如这样：

image.png

还有很多的很多的功能，比如routine，teach a task等。我特意去他的dashboard上看了下他模型的调用情况，模型大部分都是使用的Grok4.6，还有的时候会使用opus5，都是目前最顶级的大模型。并且额度很耐用，跑了一天的GrokBot，周额度才用21%。今天新开的小说是他们做的，从写作到发布全程没动收，全是他们做的。他们一天都在写作，先本地写好md文件，记忆文件，人物文件等等，然后去使用虚拟鼠标在他们的电脑里面上传草稿到我的番茄小说作家助手后台，然后经过我的同意去发布小说。要是经历过Window无法使用codex 的Computer Use的痛苦就懂了。在codex上跑这套流程，不知道要踩坑多少次，烧多少额度，花多少时间（codex龟速）。

额外的话

其实本来是想着第一次拿到工资的时候写一篇手记的，但是发工资的时间跟本篇的说的事情重叠了，由于GrokBot实在是太好用了，我还是决定写GrokBot，虽然可能没写出GrokBot到底有多强大。亏损了330大洋， 换来了不是我刚需的最新的Ai产品的使用权，我不知道是福还是祸，只能说“塞翁失马，焉知非福”

看完了？说点什么呢

]]>https://sin6626.me/notes/8https://sin6626.me/notes/8Thu, 13 Aug 2026 16:19:21 GMT<![CDATA[gsap官方文档的更新和Svg线条动画的探索]]>
该渲染由 Shiro API 生成，可能存在排版问题，最佳体验请前往：https://sin6626.me/notes/7

想想这篇文章应该是要发到博文才对的，但是感觉应该更多的去诉说出我的心情与感受，所以还是放在手记里吧

两件事

主要想要记录两件事情, 第一件事情让我很激动, 从早上激动到下午, 因为我上周提出的有关gsap官方文档的issue建议被官方采纳了! 今天一早上起来就看见gsap官方给我发的邮件了. 第二件事情让我感觉很有意义, 因为我发现了我平时所研究的东西在3年前也有前辈跟我研究一样的东西.

第一次提出issue建议被采纳

睡醒查看手机信息的时候, 我惊喜的发现有两封邮箱, 标题赫然写着"Re: [greensock/GSAP] Docs: clarify Vue refs in gsap.context() scope examples (Issue #652)". 内容是:

image.png

我迫不及待的就把信息发给我了我的同事和技术群的兄弟们, 因为太激动了啊, 第一次提出issue, 第一次被官方回应.虽然不是PR被合并, 但是也很高兴了.

回顾下上周五:

昨天项目的UI还没设计出来, 所以依旧是带薪学习的一天, 我把我的UI&Animation项目(还在开发中)的动画重构加收藏之后, 就继续开始了gsap文档的阅读, 主要是看入门gsap方面的文档, 看完后, 去找了一个使用了Nuxt4 + gsap的开源项目, 想去看看别人是如何在Vue使用gsap的. 我在项目中看见gsap.content() 的时候的时候就很疑惑, 因为gsap官网文档哪里, 总是说什么ref, 但是都是对于React和Angular的ref, 没有对于Vue的ref的说明. 但是我看项目使用的时候明明不是用的ref对象, 是把ref对象给.value取出了真正的dom元素的.

于是就跟技术群里的兄弟们说gsap官方偏心, 只给React和Angular说明, 没有给Vue一点情报, 文档太容易误解了. 没想到群内的Guoxk大捞直接让我提一个PR去, 这可给我吓到了, 我压根都想过这种事情.

image.png

当然还有群内的糖糖

image.png

因为github上gsap官方仓库上没有记录文档的内容, 所以提PR也不会被合并, 于是我就提了一个issue

image.png

然后就是到今天的回复了.

今天下午有关Svg的研究

今天下午继续研究BenjaminOddou的portfolio项目, 也是收集到了很多很有用的动画, 就有Svg线条动画.

这个动画让我感觉很有意义, 不是说这个动画有多么的实用(虽然可能真的很实用), 有多么的高深, 只是因为在3年前, Nuxt核心团队成员, unocss的创始人 ---- Anthony Fu(一个托尼) 大佬也曾研究过这个动画, 我喜欢的大佬曾经也研究过的动画.这个消息还是我今天下午问了群内的Guoxk大捞有关Svg图片制作才知道的. 托尼老师发的博客 -> To Blog (动画详细博客中有, 就不解释了)

这件事情为什么也想记录下呢, 感觉很单纯, 单纯因为前端的前辈大佬们曾经也经历这段学习, 就让人感觉自己的研究是有价值的. 平时有关内容驱动式网站, 组件, 动画等等的学习, 我觉得真的很有意义, 现在可能没有使用上很多次, 也用的很不熟练, 没有那种实用性上的意义, 但是这份技术的宝藏会一直在这里, 待人来发掘.

三年前的月，也曾照过那些探索 SVG 动画的人；今日我所见之光，亦是他们曾追寻过的光。

看完了？说点什么呢

]]>https://sin6626.me/notes/7https://sin6626.me/notes/7Tue, 28 Jul 2026 14:59:32 GMT<![CDATA[NestJS学习]]>
该渲染由 Shiro API 生成，可能存在排版问题，最佳体验请前往：https://sin6626.me/posts/study&think/nestjs-learning

前言

最近花时间学了 NestJS，从一个「听说过但没碰过」的状态，到能搭出一个完整的后端项目。这篇东西算是一个学习记录，把过程中的理解、踩过的坑、对框架的感悟写下来，也算是对自己这段时间的一个交代。

我对 NestJS 的理解

刚接触的时候，最直观的感受是：它和传统的 Node.js 框架不太一样。

以前写 Express ，都是"需要什么自己加"，很灵活，但也容易写散。NestJS 给我的感觉是 —— 它把规矩定好了。模块怎么拆、代码放哪里、请求怎么流转，都有一套明确的规范。

刚开始觉得有点束缚，但写多了发现，这种约束其实是一种解放。项目结构不会随着代码量增加而腐烂，回头看自己写的代码，思路是清晰的。

项目结构：模块化是核心

学 NestJS 最先要理解的就是模块化。每个功能都是一个模块，模块里放控制器、服务、数据实体，各司其职：

src/
├── main.ts             # 应用入口
├── app.module.ts       # 根模块，组装所有子模块
├── user/               # 用户模块
├── auth/               # 认证模块
├── roles/              # 角色模块
├── logs/               # 日志模块
├── guards/             # 自定义守卫
├── filters/            # 异常过滤器
├── interceptors/       # 拦截器
├── decorators/         # 自定义装饰器
├── enum/               # 常量枚举
└── utils/              # 工具函数

每个模块就像一个小盒子，有自己的职责，也能和其他模块通信。这种组织方式让项目不管多大，结构都是可预期的。

如果一个模块需要被其他多个模块复用，可以把它设为全局模块（@Global()），或者通过 exports 显式暴露出去。这种显式的依赖声明，比隐式的全局变量要健康得多。

学到最多的几个点

1. 依赖注入（DI）

NestJS 的依赖注入是我觉得最优雅的设计之一。不需要自己 new 对象，只需要在构造函数里声明需要什么，框架会自动给你注入：

constructor(private userService: UserService) {}

就一行，UserService 的实例就进来了。如果 UserService 又依赖了其他东西，框架会递归地帮你全部解析好。

这种机制带来的好处是：模块之间的耦合度低，测试也方便 —— 测试的时候可以轻松替换成 mock 对象。

2. 装饰器驱动的编程方式

NestJS 大量使用装饰器，开始的时候会觉得"到处都是 @ 符号"，看习惯了会发现这是它最方便的地方。

路由、参数提取、验证、权限控制……全都是装饰器。一个路由的处理函数，从上到下的装饰器就是它的完整"说明书"：

@Get(':id')
@UseGuards(AuthGuard)
@UsePipes(ValidationPipe)
getUser(@Param('id') id: string) { ... }

一眼就能看出来：这是个 GET 请求、需要登录、参数验证、从路径拿 id。

除了用内置装饰器，还可以自定义装饰器，把重复的逻辑封装起来。比如我写了一个 @Serialize(Dto) 装饰器，用来控制接口返回哪些字段，敏感字段不想暴露给前端，通过这个装饰器一键搞定。

3. 请求生命周期（完整流水线）

NestJS 的请求处理是一条完整的流水线，按顺序经过各个环节：

Middleware → Guard → Interceptor → Pipe → Controller → Service → Interceptor → Filter（出异常时）

每个环节各司其职：

  • Middleware：最前置的处理，可以做一些通用逻辑，比如请求日志、耗时统计
  • Guard：能不能进来？做权限校验，比如检查是否登录、是否有操作权限
  • Interceptor：进来前/出去后做点什么，比如打日志、加缓存、序列化响应数据
  • Pipe：进来的数据对不对？做参数验证和类型转换
  • Filter：出错了怎么返回？统一异常响应格式

理解了这条流水线，写代码的时候就能清楚当前逻辑该放在哪个环节，出 bug 也能快速定位。

4. TypeORM 的数据库操作

数据库用了 TypeORM，最大的感受是：操作数据库像操作对象一样自然。

最常用的几种关系：

  • 一对一：用户 ↔ 资料（一个用户只有一个资料页）
  • 一对多：用户 ↔ 日志（一个用户有多条操作记录）
  • 多对多：用户 ↔ 角色（一个用户可以有多个角色，一个角色也可以有多个用户，通过中间表关联）

常规的增删改查直接用 Repository 的方法就行。复杂查询用 QueryBuilder，写起来和写 SQL 差不多但更安全（参数化查询），支持分组、排序、分页等高级操作。

5. 数据验证与转换

验证：以前写接口的时候，参数校验经常是手写 if-else，又臭又长。NestJS 搭配 class-validator，用装饰器声明规则，简洁很多：

@IsString()
@IsNotEmpty()
@Length(2, 20)
username: string;

配合全局注册的 ValidationPipe，请求进来的时候自动校验，不合法直接返回 400，Controller 里拿到的数据一定是合法的。

转换：用 class-transformer 配合拦截器，可以控制接口返回的数据结构。比如把 User 实体转成 UserDto，只暴露前端需要的字段，密码、加密盐这些敏感字段自动过滤掉。这在写 API 的时候非常实用。

6. 认证与授权 (JWT)

用户认证用的是 JWT（JSON Web Token）方案。流程大概是：

  1. 用户登录，服务端验证用户名密码
  2. 验证通过，生成一个加密的 token 返回给前端
  3. 前端后续请求带上这个 token
  4. 服务端通过 Guards 校验 token，确定用户身份

密码不能明文存数据库，我用了第三方的包做加盐哈希处理（bcrypt），就算数据库泄露了，密码也是安全的。

权限控制方面还学了 CASL 这个库，可以定义细粒度的权限规则，比如"普通用户只能看自己的文章，管理员可以删任何文章"，配合自定义守卫来实现。

7. 环境配置管理

用 @nestjs/config 配合 .env 文件做环境配置。不同环境用不同的文件：

.env.development    # 开发环境
.env.production     # 生产环境
.env.test           # 测试环境
.env                # 公共默认配置

数据库连接信息、JWT 密钥、端口号这些都放在环境变量里，不写死在代码中。还用了 Joi 做配置验证，启动时如果缺少必要的配置项，程序会直接报错，避免带着错误配置上线。

8. 日志系统

用 nestjs-pino 做日志记录，配置了双输出：

  • 控制台：彩色格式化输出，开发时看着清晰
  • 文件：按天轮转，每个文件有大小限制，自动归档

日志记录了每次请求的路径、方法、参数、耗时等信息，线上排查问题的时候很有帮助。

9. 测试（Jest）

写了单元测试和端到端（e2e）测试。

单元测试：针对 Service 和 Controller 单独测试，用 mock 替换数据库操作，跑得很快。主要测业务逻辑是否正确。

端到端测试：模拟真实的 HTTP 请求，从路由到数据库全链路验证，确保接口整体功能正常。

用 Jest + Supertest 来写，虽然写测试确实多花一些时间，但改代码的时候有测试兜底，心里会踏实很多。

10. 异常过滤器

没有异常过滤器的时候，每个接口出错返回的格式可能都不一样。前端对接起来很痛苦。

NestJS 的异常过滤器可以把异常处理收拢到一处，统一返回格式：

{
  "code": 400,
  "message": "参数错误",
  "timestamp": "2026-07-26T00:00:00.000Z",
  "path": "/api/v1/user",
  "method": "POST"
}

不管是参数校验失败、数据库报错、还是业务逻辑异常，返回格式都是统一的。前端直接按统一格式处理就行。

写在最后

NestJS 不是那种"学完就能炫技"的框架，它更像一个规规矩矩的框架，提供了写后端应用的一整套方法论。回头看我以前用 Express 写的项目，如果当初用 NestJS，结构应该会清晰很多。

这次学的东西挺多的：模块化架构、依赖注入、TypeORM 数据操作、JWT 认证、数据验证与转换、日志系统、单元测试和 e2e 测试、自定义装饰器和守卫、异常过滤、环境配置管理……每一样在生产中都是很实用的。

框架只是一个工具，但好的工具确实能帮人写出更干净的代码。但这次学习让我最大的收获不是记住了多少 API，而是理解了这套架构思维。未来写任何后端项目，这套思维方式都是通用的。

（其实在学的过程很难受，网上没有很好入门的NestJS课程，我看的这套很不适合小白入门，里面很绕，而且课程很老，不过老师水平确实高，好在硬着头皮学完了，但是说实话不一定记住了常见的API，因为自己代码量不够多。不过，后面肯定有要用到NestJS的时候，到那时候再提高吧）

一步一个脚印，比什么都重要。

看完了？说点什么呢

]]>https://sin6626.me/posts/study&think/nestjs-learninghttps://sin6626.me/posts/study&think/nestjs-learningSun, 26 Jul 2026 15:59:16 GMT<![CDATA[Protfolio Template - Home Page - GLM的总结]]>
该渲染由 Shiro API 生成，可能存在排版问题，最佳体验请前往：https://sin6626.me/posts/source-code-study/portfolio-template-ai

Tailwind / Nuxt UI 经典套路速查

本项目开发过程中累积的高频、可直接复用的样式搭配速查表。 涵盖定位、毛玻璃浮岛、Tailwind 4 新语法、Nuxt UI 主题色别名、动效联动等。

一、定位 / 居中三件套

任意宽度元素的绝对居中(最经典)

<div class="fixed left-1/2 -translate-x-1/2">
  ...
</div>
  • left-1/2:把元素左上角点放到屏幕水平中线
  • -translate-x-1/2:再回拉自身宽度的一半,实现真正的几何居中
  • 不依赖具体 px,任意宽度都居中,比 margin-left: -w/2 优雅

顶部悬浮岛(常用于导航 / FAB)

<div class="fixed top-2 sm:top-4 left-1/2 -translate-x-1/2 z-10">
  ...
</div>

参考本项目的 app/components/AppHeader.vue。

二、毛玻璃浮岛(macOS 风)

<div class="
  bg-muted/80
  backdrop-blur-sm
  rounded-full
  border border-muted/50
  shadow-lg shadow-neutral-950/5
">
  ...
</div>

拆解:

Class含义
bg-muted/80Nuxt UI 主题色 muted 80% 透明,做模糊基底
backdrop-blur-sm模糊背后内容,核心的「毛玻璃」质感
rounded-full胶囊化(两端半圆)
border border-muted/50同色更淡的描边,做精细分层
shadow-lg shadow-neutral-950/5Tailwind 4 拆分写法,大小 + 颜色独立,亮色场景的淡阴影(5%的透明度)不突兀

适用:任何浮层、popover、浮动按钮、顶部导航胶囊。

三、Tailwind 4 新语法(高频三招)

1️⃣ 任意 CSS 变量值

<div class="max-w-(--ui-container)">

等价于 max-width: var(--ui-container),括号内可放任意 CSS variable,替代旧版 max-w-[1400px] 死值。

2️⃣ data-attr 状态选择器

<!-- 本元素状态 -->
<button class="data-[state=active]:text-highlighted data-[state=inactive]:text-muted">

<!-- 父级挂 group 时,子元素响应父级 data-state -->
<div class="group">
  <Icon class="group-data-[state=open]:rotate-135" />
</div>

配合 Reka UI / Nuxt UI 的 data-state 自动 toggle,纯 CSS 响应组件状态,不写 JS 切 class。

3️⃣ important 后缀

<div class="pt-0! px-0!">

Tailwind 4 把 ! 移到末尾(旧版是 !pt-0)。压第三方库默认样式必备——比如压过 Nuxt UI 组件自带的 padding/ring。

四、响应式出血 + 兼容器锁宽

「让某区块出血到全宽,但又被 UI 容器限宽」的经典组合:

<div class="-mx-4 sm:-mx-12 lg:-mx-16 max-w-(--ui-container)">
Class含义
-mx-4 sm:-mx-12 lg:-mx-16负边距让区块反向吃掉父级 padding,出血到内容边
max-w-(--ui-container)但又被 Nuxt UI 容器宽度锁住,不会越界

参考本项目 app/components/landing/Testimonials.vue 的 UCarousel viewport 配置。

五、before: / after: 伪元素装饰

父 hover 子才显 + 滑一下(三件套)

<div class="group">
  <UIcon class="
    opacity-0
    group-hover:opacity-100
    group-hover:translate-x-1
    transition-all
  " />
</div>
  • 父级挂 group
  • 子元素常驻隐藏(opacity-0)
  • group-hover:*:父级 hover 时子才响应
  • 配 transition-all 做丝滑过渡

参考本项目 app/components/landing/Blog.vue 的 "Read Article" 箭头按钮。

适用:hover 时才渐显的图标、徽章、箭头、装饰元素。

大引号装饰

<p class="
  before:content-[open-quote]
  before:text-7xl
  before:text-dimmed
  before:absolute
  before:-ml-10
  before:-mt-4
  after:content-[close-quote]
  after:...对称
">
  推荐语正文...
</p>

关键点:content-[open-quote] 是 Tailwind 4 任意值语法,编译成 content: open-quote,引号自动按文档 lang 渲染(英文 " / 中文 「」)。

参考本项目 app/components/landing/Testimonials.vue 的 UPageCTA。

六、Nuxt UI 主题色别名(Semantic Colors)

这些 class 在 Tailwind 官网搜不到,但项目里到处都是。查看 Nuxt UI 主题文档。

颜色别名

别名含义
bg-default默认页面背景
bg-muted次要表面色(卡片淡底)
bg-elevated凸起表面(卡片 / 浮层 / 选中态),比 muted 稍亮
bg-accented进一步加 accent
bg-highlighted高亮选中
bg-inverted反色背景
text-default主文本色
text-muted次要文字
text-dimmed极次文字(装饰元素、图标描边常驻)
text-hi强调文字
text-inverted反色文字

高频组合

半透卡片底

<div class="bg-elevated/60">...</div>

60% 透明的凸起色,做卡片「轻微浮起」感。

hover 轻微反馈

<div class="hover:bg-muted/50">...</div>

鼠标进入变次要色 50% 透明,轻微 hover 反馈,不抢眼。

激活态文字色切换(Nuxt UI 标配!)

<button class="
  data-[state=active]:text-highlighted
  data-[state=inactive]:text-muted
">
  ...
</button>

Reka UI 状态切换时自动 toggle data-state,纯 CSS 被动响应。

参考本项目 app/components/landing/FAQ.vue 的 UTabs 样式覆盖。

七、group + group-hover: 联动机制

父级挂 group,子用 group-hover:* 响应父级 hover——Tailwind 不写 JS 切 class 的核心模式。

<div class="group">
  <!-- 子元素常驻不可见,鼠标 hover 到父级任意位置时才显 -->
  <Icon class="opacity-0 group-hover:opacity-100 group-hover:translate-x-1 transition-all" />
</div>

要点:

  • 子元素自己常驻隐藏(opacity-0),鼠标根本 hover 不到它
  • 鼠标 hover 父级任意位置 → 子响应
  • 配合 group-data-[state=open]:* 还能响应父级特定 data-state

网页动效 80% 的 hover 联动都靠它,React / Vue 项目通用。

八、动画性能套件

折叠 / 抽屉 / Tab 切换等动画场景,给做 transform 的元素加这两个,防掉帧:

<div class="transform-gpu will-change-transform">
  ...
</div>
Class含义
transform-gpu强制该元素用 GPU 合成层渲染
will-change-transformCSS hint,提前告诉浏览器「这元素的 transform 即将变化」,提前优化

参考本项目 app/components/landing/FAQ.vue 的 UAccordion trigger 样式。

九、其他常用速记

场景Class 串
长文字省略号truncate (= overflow:hidden; text-overflow:ellipsis; white-space:nowrap)
短文本行宽平衡text-balance(浏览器自动平衡每行长度,推荐语尾部不会只剩 1-2 字)
防止意外换行text-nowrap
紧凑卡片悬停反馈hover:bg-muted/50 + rounded-lg + px-3 py-2

完整 Cheatsheet

场景关键 class 串
顶部悬浮居中浮岛fixed top-X left-1/2 -translate-x-1/2 z-10
毛玻璃胶囊bg-muted/80 backdrop-blur-sm rounded-full border border-muted/50 shadow-lg shadow-neutral-950/5
父 hover 子才显 + 滑一下opacity-0 group-hover:opacity-100 group-hover:translate-x-1 transition-all(父挂 group)
压过第三方默认样式pt-0! / px-0!(Tailwind 4 important 后缀)
Reka UI 状态切文字色data-[state=active]:text-highlighted data-[state=inactive]:text-muted
子元素响应父级 data-stategroup-data-[state=open]:rotate-135(父挂 group)
出血到全宽 + 锁 UI 容器宽-mx-4 sm:-mx-12 lg:-mx-16 max-w-(--ui-container)
装饰性 CSS 大引号before:content-[open-quote] before:text-7xl before:absolute before:-ml-10
动画不卡 GPU 提升transform-gpu will-change-transform
简单大字 + 平衡行宽text-balance
防换行text-nowrap
长文字省略号truncate
半透卡片底bg-elevated/60
hover 轻微反馈hover:bg-muted/50

常见疑问

Q: 为什么 bg-elevated / text-muted 等在 Tailwind 官网搜不到?

A: 这些是 Nuxt UI 自己注入的语义化颜色别名(Semantic Colors),基于 CSS 变量,自动跟随 light/dark 模式切换。要在 Nuxt UI 主题文档 的 Semantic Colors 章节查,不是 Tailwind 原生类。

Q: ! 后缀是什么?

A: Tailwind 4 的 important 语法,放在 class 末尾(如 pt-0!),等价于 padding-top: 0 !important,主要用来压过第三方库的默认样式。

Q: group 和 group-hover: 必须配套吗?

A: 是的。group 标在父级,group-hover:* 才能在父级 hover 时生效。单独写 group-hover:* 而父级没 group,Tailwind 不会识别父级关系,会失效。

后续遇到新的经典套路继续追加到本文档。

看完了？说点什么呢

]]>https://sin6626.me/posts/source-code-study/portfolio-template-aihttps://sin6626.me/posts/source-code-study/portfolio-template-aiMon, 20 Jul 2026 13:56:07 GMT<![CDATA[Zod]]>
该渲染由 Shiro API 生成，可能存在排版问题，最佳体验请前往：https://sin6626.me/posts/study&think/zod

Zod的学习, 非技术分享

什么是Zod

Zod 是一个 帮助Ts的使用者们在Ts的编写和运行时，进行类型的推断和校验的库，极大的维护了Ts类型安全，0外部依赖， 轻巧，十分流行。

Zod的简单用法

下面是在NuxtContent里面看见的Zod的用法，今天看文档的时候看见了Zod，发现不会使用于是就学习了下

// 代码
      schema: z.object({
        // Hero 区: CTA 按钮组 + 跑马灯图片组
        hero: z.object({
          links: z.array(createButtonSchema()),
          images: z.array(createImageSchema())
        }),

Zod的用法很简单，简单到把上面的代码翻译一遍给你听你就知道他应该如何去使用了

  • schema必须是一个对象类型，下面必须要有hero属性
  • hero属性必须是一个对象，必须要有links和images属性
  • links必须是一个数组，并且数组内的元素类型必须是creatButtonSchema() 这个方法的返回值类型，或者说通过这个返回值的校验（这个方法名的后缀是Schema其实从侧面说明了，这个方法的返回值也是一个z。object约束的对象）
  • images跟links同理 对吧，就是一看就会，一用也会（大概？）。然后你可以使用parse() 去验证你的数据，好比这样schema.parse(data)。如果在运行的时候parse的校验没有通过，那么会直接报错，而Ts只有当你使用这种错误数据类型的时候才会报错（比如你在String类型上使用了toFixed方法），这样也说明了他比Ts更加的安全，注重运行的数据安全。

如果你不希望他在运行时报错，你可以使用safeParse(使用这个api往往表示你希望数据是正确的)，方法会返回一个对象：

// 代码
{
  success:false,
  error:ZodError
}

如果数据正确则会返回这样的对象：

// 代码
{
  success:true,
  data:{
    name:"Tom",
    age:18
  }
}

在使用Ts的前端开发中，你想要去校验一个表单数据，不需要先interface 再去写校验数据逻辑了， 直接可以使用Zod去规定一个schema， 然后使用parse去验证，或者使用type register = z.infer直接生成一个interface，而且还有校验的规则。

// 代码
const RegisterSchema=z.object({

 username:z.string(),

 age:z.number()

})


type RegisterForm = z.infer<typeof RegisterSchema>

总结

Zod的出现给运行时候的Ts代码套上一层安全的外壳，也简便了一些基础的校验规则，更多特性等有需求的时候再看吧。

看完了？说点什么呢

]]>https://sin6626.me/posts/study&think/zodhttps://sin6626.me/posts/study&think/zodWed, 15 Jul 2026 14:28:03 GMT