做一个后台页面，真正让人磨蹭的，常常不是多复杂的算法。输入框旁边放什么提示，没填内容怎么报错，表格里的按钮怎么对齐，换个页面以后样式又是不是同一套——这些零碎活，做第二遍就有点烦了。
Semi Design 适合从这里看。它是抖音前端团队维护的 React 组件库和设计系统，表单、表格、弹窗这些常用部件已经准备好。你负责把业务接进去，不用先从画一个按钮开始。
它不是下载后就能用的后台系统
先分清这一点，能省不少时间：Semi 不会替你准备用户数据库、登录接口和权限规则，也不是换上就能运行的 Typecho 主题。它提供的是写前端时能拿来组合的部件。
比如做一个资料管理页，表单用来填名称，表格用来显示条目，弹窗用来确认修改。控件的外观和不少交互可以沿用 Semi，数据从哪来、谁能修改、怎样保存，仍是项目自己的工作。
所以它更适合已经在写 React、正要做管理台或内部工具的人。如果只想给博客换个皮肤，不想碰 JavaScript 和构建工具，这套东西反而绕远了。已有一套用得顺手的组件库，也没必要只为几张漂亮动图，把整个项目迁过来。
先做一个表单，比先研究整套设计系统更实在
第一次看这类项目，很容易顺着介绍一路看到主题商店、设计插件，再回头发现自己连一个输入框都没接上。可以先把目标缩小：填一个工具名称，点提交，在页面里看到提交的数据。
下面按已有的普通客户端 React 工程说明，需要机器上已有 Node.js、包管理器，且工程本身能正常启动。不是把代码直接粘进网页后台。本篇没有在本机安装或运行 Semi，示例依据官方接口整理，执行结果需要你在自己的工程里核对。
在项目根目录，也就是能看到 package.json 的位置，安装组件包。本次资料核对以 2.104.0 为参考版本：
npm install @douyinfe/semi-ui@2.104.0React 版本先看自己项目的 package.json。按当前仓库的快速开始及 React 19 适配说明，React 16、17、18、19 使用同一个包；React 19 要在入口文件最顶部、任何 Semi 组件被使用之前，加上这一行：
// main.jsx / main.tsx，仅 React 19 工程需要
import '@douyinfe/semi-ui/react19-adapter';网上仍能找到让 React 19 改装 @douyinfe/semi-ui-19 的旧说明，不要把两套接法混在一起。维护旧工程时，先看锁定版本对应的文档；也不要为了试组件库顺手升级整套 React。
在单独的练习工程里，把下面内容放进已被入口引用的 App.jsx。正式工程不要直接覆盖现有页面，另建练习组件再挂载。若用 TypeScript，可以先在允许 JSX 的练习工程照着理解，类型收紧留到自己的代码里处理。
import { useState } from 'react';
import { Button, Form } from '@douyinfe/semi-ui';
export default function App() {
const [submitted, setSubmitted] = useState(null);
return (
<main style={{ maxWidth: 520, margin: '40px auto', padding: 20 }}>
<h1>记录一个工具</h1>
<Form onSubmit={values => setSubmitted(values)}>
<Form.Input
field="name"
label="工具名称"
placeholder="例如：资料整理助手"
rules={[{ required: true, message: '先填一个名称' }]}
/>
<Form.TextArea
field="note"
label="准备拿它做什么"
placeholder="写一句用途就够了"
/>
<Button htmlType="submit" theme="solid" type="primary">
检查提交内容
</Button>
</Form>
{submitted && <pre>{JSON.stringify(submitted, null, 2)}</pre>}
</main>
);
}沿用工程原有的启动方式打开页面。先空着名称提交，再填入名称和用途提交，检查必填提示以及下方 JSON 的字段。这里要核对的不是“按钮能不能点”，而是表单收集的内容是不是自己刚刚填写的。
field="name" 对应提交结果里的 name；Form.Input 和 Form.TextArea 是 Form 包装过的控件，表单会管理它们的数据。别把普通 Input 随便换进来，又以为它一定会自动进入提交结果。默认值可用 initValue 或表单的 initValues，不必再给每个字段手写一套状态同步。
这个小例子只把结果放进页面内存，刷新就没有了，没有保存到服务器。接正式业务时，需要在提交回调里调用自己的接口，补上服务端校验和错误反馈。界面上的“必填”检查，不能代替后端检查。
表单通了，再看 Table 文档会轻松些：columns 定义每列显示什么，dataSource 提供每一行的数据，每行要有稳定且唯一的标识。先用两三条假数据确认布局，再接真实接口，不必第一次就把筛选、分页和行编辑一起做完。
项目颜色不一样，别急着一条条覆盖 CSS
默认控件能用了，下一步往往是“这个蓝色不太像我们的产品”。只改一个按钮容易，改到悬停、按下、禁用，再碰到输入框和弹窗，零散覆盖很快就不好维护。
Semi 的主题方案值得在这个阶段再看。它把颜色、字体、圆角等设计值整理成可复用的变量，DSM 则提供了管理设计系统的工具。你调整的是一套约定，而不是记住每个组件内部的选择器。
刚开始不必为此建一整套公司级规范。先选一个页面，看默认主题是否合适；确实要定制，再按所用构建工具接主题方案。默认组件引入和定制主题的构建配置是两回事，不能拿一条安装命令概括全部情况。
深色模式也类似。Semi 有配套色盘，但自己写死成白底黑字的业务区域，不会因为组件换了主题就自动协调。检查时把正文、背景、提示和禁用状态一起看，别只看按钮颜色。
README 里那些 GIF，演示的是另一段工作
这也是 Semi 比单纯“按钮合集”更值得留意的地方：它还在处理设计稿交给开发之后，那段反复对照尺寸和样式的工作。
官方把设计稿转代码这部分叫 D2C。README 展示了 Figma 插件和 Dev Mode 中的使用方式，还演示了转到 CodeSandbox 继续编辑代码的流程。对于本来就在用 Figma 和 Semi 组件的团队，这比照着截图重新量间距更有吸引力。
不过，先别把“出了代码”理解成“项目已经做好”。生成的界面仍要读一遍：数据有没有接上，按钮是不是只有样子，错误和空状态有没有处理，窄屏是否能用。这些属于业务验收，不会在一张漂亮的设计稿里自动补齐。
Figma、插件及在线编辑环境也各有账号、服务和访问条件。图里的演示界面不一定与今天完全相同，是否适合你的工作流，要单独核对；不能从组件库采用 MIT 许可，就推导出相关在线服务全部免费、全部可离线使用。
如果你是一个人做小工具，没有设计师交稿，暂时忽略 D2C 完全没关系。先把前面那个表单做明白，收益反而更直接。
值不值得用，拿一页真实需求判断
我会把 Semi 放进 React 管理台、资料录入页和内部工具的候选里。理由不是组件数量，而是这些页面经常同时需要表单、数据展示和一致的状态样式，正好能用到它提供的基础。
挑一个你确实要做的页面，列出必须有的控件，再翻官方示例看能不能接近需求。若还要大量绕过默认行为、全局覆盖样式，就值得停下来比较别的方案。已经维护得很稳定的旧系统，不必为了统一视觉，先承担一次大迁移。
普通用户想找一款装好就能整理资料的软件，这篇不是那个方向；开发者想少写一遍基础控件，则可以从一个表单开始，而不是先把整套设计系统研究完。
https://github.com/DouyinFE/semi-design
