今天苏米要分享的这个独立开发者思路，非常值得学习：把“骨架屏”从手工活变成自动产物。希望能给你的独立开发之路带来更高的效率和更少的重复劳动。
在前端世界里，有一件事几乎每个人都干过——写骨架屏（Skeleton）。常见做法无非两种：
- 用 Ant Design 这类组件库拼一个
- 或者自己手写一套骨架组件
问题也很现实：
- 想做到“和真实 UI 完全一致”，代码会非常多
- 一旦 UI 改了，骨架屏很容易忘记同步
- 布局复杂一点（卡片、列表、嵌套结构），基本就是体力活
🚀 Boneyard：拒绝手写骨架屏
最近有个项目开始在圈子里刷屏 —— Boneyard。
它做了一件很“反常识”的事：
- ❌ 不再手写 Skeleton
- ✅ 直接从真实页面“生成 Skeleton”
- 让骨架屏不再是 UI，而是“编译产物”
这背后的价值很直接：UI 怎么变，骨架屏就怎么跟；不再为改了一行 CSS 去补一堆占位结构。
🧠 它到底是怎么做到的？
Boneyard 的核心思路是：在构建阶段，把真实 UI “拍扁”成骨架数据，然后在运行时按数据渲染骨架。
用更直白的话说：
- 在构建时无头浏览器打开你的页面/组件，读取每个元素的坐标、尺寸、圆角等
- 过滤掉看不见或无需占位的元素（如透明、display:none 等）
- 把这些信息写进一个数据文件，供运行时直接绘制骨架层
这样一来，“骨架屏”就不再是另一套 UI，而是你的真实 UI 的一个“快照轮廓”。
核心工作流（非常关键）
- 正常写你的组件，你不需要写任何骨架 UI：
小贴士：把组件包在 Skeleton 里，Boneyard 才知道要为这个“name”生成数据。
- 运行 CLI 生成骨架
npx boneyard-js build这一步才是核心：它会启动浏览器（Playwright）扫描 DOM，记录所有元素的位置和尺寸，最终生成一份数据文件：
.bones.json。本质就是：UI → 坐标数据（x / y / width / height / radius）。它还可以按断点收集不同尺寸下的数据，避免响应式错位。
- 运行时直接渲染
不再依赖真实组件，只渲染“骨架数据”。这让首屏更轻，渲染也更稳定。
实践要点（建议）：
- 用接近真实的数据源或 mock 数据执行构建，这样骨架更贴近上线效果
- 把
build加入 CI，每次 UI 改动都同步刷新骨架数据 - 多端/多断点页面单独生成，避免在移动端出现桌面布局的骨架
⚡ 如何快速上手？
- 安装
npm install boneyard-js - 包裹组件
- 生成骨架
npx boneyard-js build完成之后就可以直接用了。
上手注意：
- 需要可用的本地/预览环境让 Playwright 能渲染页面
- 颜色、动效通常可在 Skeleton 运行时配置（比如浅灰、呼吸动画），与业务解耦
- UI 大幅调整后记得重建，否则骨架可能偏移
🌍 支持哪些框架？
这是 Boneyard 很有意思的一点：它本质是跨框架的。
- ✅ 官方支持：React、React Native、Svelte 5
- 🧩 Vue 也能用（社区版本）
对多端和多技术栈的团队而言，统一“骨架生成方式”，维护成本会下降一大截。
🧩 Vue 也能用（社区版本）
虽然官方还没有 Vue 版本，但社区已经有人做了适配 —— boneyard-vue。它本质上做了一件事：用 Vue 实现 Skeleton 运行时。
所以你可以这样写：
小提醒：
- 社区实现可能跟进节奏不一，升级注意版本匹配
- SSR/CSR 项目注意在客户端渲染时再启用骨架数据，避免水合冲突
💥 写在最后
Boneyard 本质是在做一件事：把“骨架屏”从手工活，变成编译产物。
如果说过去 20 年：前端在“写 UI”，那 Boneyard 在做的是：让 UI 的“加载态”也进入编译时代。
当 Skeleton 都开始被编译：那未来会不会是：
- loading 不再写
- animation 不再写
- 甚至 UI 也不再“手写”
更务实的建议：
- 适合：页面结构稳定、样式变化频繁的中大型项目；设计追求一致性的团队
- 不适合：布局高度依赖实时尺寸/用户配置的页面（需要更细粒度控制）
- 与 Suspense/流式渲染并不冲突：可以把骨架当作更贴合真实布局的 fallback
🔗 相关链接
- Boneyard 官网：https://boneyard.vercel.app/overview
- Boneyard Vue：https://github.com/samuelbelo/boneyard-vue