先把粒子撒成螺旋

星系的骨架是「分支 + 旋转偏移」。把每个粒子分配到某一条旋臂上，再让半径越大的粒子偏转越多，螺旋就出现了：

const BRANCHES = 4
const SPIN = 1.15

for (let i = 0; i < count; i++) {
  // 幂次让粒子向核心聚集，比均匀分布自然得多
  const r = Math.pow(Math.random(), 0.8) * RADIUS
  const branchAngle = ((i % BRANCHES) / BRANCHES) * Math.PI * 2
  const spinAngle = r * SPIN

  positions[i * 3 + 0] = Math.cos(branchAngle + spinAngle) * r
  positions[i * 3 + 1] = 0
  positions[i * 3 + 2] = Math.sin(branchAngle + spinAngle) * r
}

这时候的星系整齐得像个风扇。真实的星云是「毛茸茸」的 —— 给每个轴叠加一个幂律随机偏移，幂次越高，粒子越贴近旋臂：

const rand = () =>
  Math.pow(Math.random(), 2.9) *          // 幂律：大偏移很罕见
  (Math.random() < 0.5 ? 1 : -1) *        // 正负对称
  0.44 * (r + 0.6)                        // 半径越大越松散

颜色是三段插值

从核心到边缘，我用了三段颜色：核心是恒星密集的暖金，中段过渡到品红，外围随机混入极光青或紫。诀窍是在 JS 里算好颜色塞进 attribute，着色器里只做透明度：

const inside = new THREE.Color('#ffd27d')
const mid    = new THREE.Color('#f973c0')
const outer  = Math.random() < 0.5
  ? new THREE.Color('#6ee7f9')
  : new THREE.Color('#a88bfa')

const t = r / RADIUS
tmp.copy(inside)
t < 0.45
  ? tmp.lerp(mid, t / 0.45)
  : tmp.copy(mid).lerp(outer, (t - 0.45) / 0.55)

差速旋转：星系活起来的关键

如果整个星系用同一个角速度旋转，看起来就是一张贴图在转盘上打转。真实星系是差速旋转的 —— 越靠近核心转得越快。把旋转搬进顶点着色器，每颗粒子按自己的半径算角度：

uniform float uTime;

void main() {
  vec3 p = position;

  float dist  = length(p.xz);
  float angle = atan(p.x, p.z)
              + uTime * 0.24 / (dist * 0.55 + 0.35); // 核心快、边缘慢

  p.x = sin(angle) * dist;
  p.z = cos(angle) * dist;

  vec4 mv = modelViewMatrix * vec4(p, 1.0);
  gl_Position  = projectionMatrix * mv;
  gl_PointSize = uSize * aScale * (42.0 / -mv.z);   // 近大远小
}

片元着色器负责把方形点精灵变成柔光球，pow 的指数决定光晕的「硬度」：

void main() {
  float d = distance(gl_PointCoord, vec2(0.5));
  float strength = pow(1.0 - smoothstep(0.0, 0.5, d), 3.0);
  gl_FragColor = vec4(vColor, strength);
}

最后开加法混合，粒子重叠处自动过曝成辉光，核心不点灯自己就会发光：

new THREE.ShaderMaterial({
  transparent: true,
  depthWrite: false,               // 关键：否则粒子会互相裁剪
  blending: THREE.AdditiveBlending,
  vertexColors: true,
})

踩过的坑

depthWrite: false 忘了关，粒子边缘出现黑色方块，查了一个小时。加法混合 + 深度写入是互斥的，切记。

• gl_PointSize 要乘 devicePixelRatio，否则高分屏上粒子小得像灰尘
• 粒子数量不是越多越好：一万颗以后提升有限，移动端直接砍半
• 旋转速度放在 uniform 里而不是每帧改 rotation，GPU 转比 CPU 转便宜得多

一万颗粒子，一次 draw call，六十行着色器 —— 这大概就是我爱上 WebGL 的原因：用最少的资源，换最大的浪漫。

为什么原生滚动「不够用」

原生滚动是阶梯式的：滚轮每格跳 100px 左右，动画跟着一顿一顿。Lenis 做的事情很简单 —— 拦截输入，把目标位置用缓动函数「追」出来：

import Lenis from 'lenis'

const lenis = new Lenis({
  duration: 1.15,
  easing: (t) => Math.min(1, 1.001 - Math.pow(2, -10 * t)),
  smoothWheel: true,
})

但装上 Lenis 只是开始。真正的坑在于：页面里现在有几个时钟？

一个页面只允许一个 rAF 循环

Lenis 要 raf，GSAP 有自己的 ticker，Three.js 还有渲染循环。三个 requestAnimationFrame 各跑各的，帧与帧之间互相踩踏，这就是「莫名卡一下」的元凶。解法是全部挂到 GSAP 的单一 ticker 上：

lenis.on('scroll', ScrollTrigger.update)

gsap.ticker.add((time) => {
  lenis.raf(time * 1000) // GSAP 用秒，Lenis 用毫秒
})
gsap.ticker.lagSmoothing(0)

从此滚动、补间、渲染共享一个心跳。

scrub 永远写数字

scrub: true 是 1:1 硬绑定，快速甩动滚轮时动画会「抽搐」。写一个数字，它就变成了追赶延迟（秒）：

gsap.to(camera.position, {
  z: 4,
  ease: 'none',
  scrollTrigger: {
    trigger: '#journey',
    start: 'top top',
    end: 'bottom bottom',
    scrub: 0.8, // 0.8 秒的“惯性”，抖动全部被抹平
  },
})

0.6 ~ 1.0 之间的值手感最好。再大就开始「晕船」了。

固定舞台，而不是 pin

滚动驱动 3D 场景时，教程都爱用 pin: true。但 pin 会克隆 DOM、改写布局，跟 Lenis、跟别的动画库打架是常事。更稳的做法是舞台固定 + 幽灵滚动条：

.stage {
  position: fixed;
  inset: 0;
  z-index: 0; /* 3D 永远铺在底下 */
}
.scroll-driver {
  height: 500vh; /* 一个透明的高个子，只负责产生滚动距离 */
}

ScrollTrigger.create({
  trigger: '.scroll-driver',
  start: 'top top',
  end: 'bottom bottom',
  scrub: 0.8,
  onUpdate: (self) => {
    world.progress = self.progress // 写进共享状态，useFrame 里读
  },
})

DOM 层滚 DOM 的，3D 层读进度做自己的事，两边解耦，谁也不干扰谁。

数值写进 ref，不写进 state

滚动进度每秒变化上百次。放进 React state，等于每秒上百次重渲染：

// ❌ 整棵组件树给你表演原地爆炸
const [progress, setProgress] = useState(0)

// ✅ 可变单例 + useFrame 直读，零重渲染
export const world = { progress: 0 }

useFrame(() => {
  camera.position.z = THREE.MathUtils.damp(
    camera.position.z,
    6.5 - world.progress * 2.6,
    2.2,
    delta,
  )
})

别忘了那 5% 的用户

平滑滚动是甜点，不是主食。prefers-reduced-motion 开启时，Lenis 干脆不要初始化：

const reduced = matchMedia('(prefers-reduced-motion: reduce)').matches
if (!reduced) initLenis()

滚动叙事的尽头是克制 —— 用户感觉不到你调了三天参数，只觉得「这网站滚起来真舒服」，那你就成功了。

1. 先测量，再动手

猜是没用的。装上 r3f-perf，让数据说话：

import { Perf } from 'r3f-perf'

<Canvas>
  <Perf position="top-left" />
  <Scene />
</Canvas>

看三个数字：draw calls、三角形数量、GPU 耗时。那个页面的初始状态：draw calls 217，三角形 340 万。目标：draw calls 50 以内，三角形 50 万以内。

2. setState 逐出 useFrame

搜一遍代码库，凡是 useFrame 里出现 setXxx 的，全部改成 ref 直改：

// ❌ 每帧一次 setState = 每帧一次协调，React 表示很累
useFrame(() => setRotation((r) => r + 0.01))

// ✅ 直接改 Three 对象，React 完全不知情
useFrame((_, delta) => {
  meshRef.current.rotation.y += delta * 0.6
})

这一步就拿回了 20fps。React 的协调器很快，但每秒 60 次全树 diff 谁也扛不住。

3. 重复物体全部实例化

场景里 90 个小行星是 90 次 draw call。InstancedMesh 合并成 1 次：

const dummy = useMemo(() => new THREE.Object3D(), [])

useFrame(() => {
  asteroids.forEach((a, i) => {
    dummy.position.copy(a.position)
    dummy.rotation.y = a.spin
    dummy.updateMatrix()
    meshRef.current.setMatrixAt(i, dummy.matrix)
  })
  meshRef.current.instanceMatrix.needsUpdate = true
})

<instancedMesh ref={meshRef} args={[undefined, undefined, 90]}>
  <icosahedronGeometry args={[0.4, 0]} />
  <meshStandardMaterial />
</instancedMesh>

217 个 draw call 降到 41 个。

4. dpr 封顶，抗锯齿关掉

4K 屏 + devicePixelRatio = 3 意味着每帧要画 2400 万像素。封顶到 2，视觉上几乎无损：

<Canvas
  dpr={[1, 2]}
  gl={{ antialias: false, powerPreference: 'high-performance' }}
>

粒子和辉光场景里 MSAA 基本看不出来，关掉换 15% 的 GPU 余量，值。

5. 灯光是奢侈品

每盏灯都是一次全场景着色计算，阴影贴图更是每帧一次额外渲染。那个页面里有 7 盏 PointLight，其中 5 盏「只是想加点氛围」：

• 氛围光交给 ambientLight + 材质的 emissive
• 真实阴影换成 drei 的 ContactShadows（烘焙一次，不逐帧算）
• 保留的动态光不超过 2 盏

6. 设备分级，移动端主动降载

最后一步是承认现实：手机 GPU 就是画不动桌面级的粒子量。入口处做一次分级：

const lowTier =
  matchMedia('(pointer: coarse)').matches || innerWidth < 768

export const quality = {
  particles: lowTier ? 4000 : 10000,
  dpr: lowTier ? [1, 1.5] : [1, 2],
  crystals: lowTier ? 4 : 7,
} as const

低端机少画一半粒子，用户只会觉得流畅，不会觉得寒酸。流畅本身就是高级感的一部分。

急救结果

性能优化最反直觉的一点：它几乎从不牺牲画面。上面六步做完，页面看起来和原来一模一样 —— 只是终于对得起那个创意了。

时间线是新闻的隐喻，不是思想的

传统博客是倒序时间线：最新的在最上面，旧文章一路沉底，仿佛写作的价值会随时间衰减。但我翻自己笔记的体验恰恰相反 —— 三年前的某段想法，常常在今天突然接上了电。

「数字花园」这个比喻我第一次听到就被击中了：

花园里没有「过期」的植物，只有长势不同的植物。有的刚发芽，有的已经开花，有的需要修剪，有的正在和别的枝条缠绕生长。

所以这个站点里，文章按主题聚集而不是按日期流放。旧文会被反复修订 —— 那不是历史记录，是还活着的想法。

写作是思考的调试器

我真正开始规律写作，是发现了一个副作用：写不清楚的地方，恰好就是没想清楚的地方。

写代码时我们有类型检查、有单元测试、有 linter。思考没有这些工具 —— 大脑非常擅长用「感觉懂了」糊弄自己。而写作会强迫所有隐式假设显式化，就像给思维过程加了一层静态检查。文章写卡住的位置，几乎精确对应理解的断层。

从这个角度说，博客发布出去有没有人看，反而是次要的。写的过程本身已经完成了大部分价值。

为什么是星云

决定重做博客时，我给自己提了个要求：这一版要「像我自己」，而不是像某个主题模板。

我最后选了星云作为整个站点的视觉隐喻，因为它和数字花园惊人地同构：

• 恒星在星云中诞生 —— 想法在笔记的尘埃里凝聚成形
• 引力让物质彼此吸引 —— 主题相近的文章自然聚集成簇
• 光要走很多年才被看见 —— 今天写下的东西，可能几年后才照到某个人

于是首页那一万颗粒子不只是炫技（好吧，也有一点），它是这个博客的自我介绍。

给同样想写的你

如果你也在犹豫要不要开始写博客，我的建议浓缩成三条：

1. 给自己写，不给算法写。 流量是副产品，别让它变成目标函数
2. 发布粗糙的版本。 花园里允许有幼苗，完美主义是写作的头号杀手
3. 拥有自己的域名和数据。 平台会倒闭、会改推荐策略，而 Markdown 文件永远是你的

这片星云会一直长下去。欢迎常来看看 —— 说不定哪颗星星，正好是你缺的那一颗。