企业官网建设流程全解析

1. 项目缘起与核心定位

第一次看到“artcraft”这个词，我的直觉是它把“art”和“craft”两个词捏在了一起——艺术与手艺。这不是一个纯技术名词，也不是一个纯设计概念，它更像是一种做事的方式：用工程化的手艺去实现有艺术感的产出。我在过去几年里陆续做过几个类似定位的小项目，有的是给独立创作者做作品集站点，有的是给小型工作室做内容管理工具，还有的是给自己折腾一套自动化的素材整理流程。这些项目有一个共同点：它们都不追求大而全，而是追求“做出来的东西好看、好用、好维护”。

artcraft 这个标题给我的第一印象，是一个面向创作者的工具集或者框架。它可能包含几个核心模块：素材管理、模板渲染、导出发布，以及一套轻量的配置系统。为什么我会这么判断？因为“art”指向的是视觉呈现和创意表达，“craft”指向的是可复用的工艺流程。两者结合，最自然的落地形态就是一个“让创作者用工程化手段管理自己作品”的项目。它解决的核心问题是：创作者往往擅长内容本身，但不擅长把内容组织成可维护、可扩展、可批量操作的结构。artcraft 要做的，就是把这层结构补上。

适合谁来参考这篇内容？如果你是一个独立开发者，想给自己或朋友做一个作品展示站点；如果你是一个小团队的技术负责人，需要一套轻量的内容管理方案；如果你是一个手工创作者，想把自己的作品数字化并批量管理；甚至如果你只是一个喜欢折腾工具的效率爱好者，这篇内容里的思路和实操步骤都能直接拿去用。我不假设你有很深的编程背景，但我会在涉及代码的地方给出足够详细的注释和解释，确保你能跟着做下来。

在展开具体内容之前，我想先说明一个原则：artcraft 这类项目的价值不在于技术有多复杂，而在于它是否真正贴合了创作者的工作流。我见过太多工具，功能列表很长，但用起来处处别扭。所以我在拆解这个项目时，会重点讲“为什么这么设计”以及“实际用起来会遇到什么问题”，而不是只列功能。

2. 整体架构与设计思路拆解

2.1 为什么选择“配置驱动”而不是“代码驱动”

artcraft 的核心设计思路，我倾向于把它定位成“配置驱动”。什么意思？就是创作者不需要写代码，只需要在一个配置文件里描述自己的作品信息、分类方式、展示样式，然后由工具自动生成最终的页面或应用。这个选择背后有几个考量。

第一，创作者的时间应该花在内容上，而不是花在调样式和改代码上。我见过不少独立创作者，为了改一个字体大小，在 CSS 文件里翻半天，最后还把布局搞乱了。配置驱动可以把常见的展示需求抽象成几个参数，改一个数字就能看到效果，不需要理解底层实现。

第二，配置驱动天然适合批量操作。比如你有 50 个作品要展示，每个作品有标题、描述、封面图、标签、链接。如果用代码驱动，你可能要写 50 个组件或者 50 段 HTML。如果用配置驱动，你只需要在一个列表里加 50 条记录，剩下的交给工具处理。这个差异在作品数量少的时候不明显，但一旦超过 20 个，配置驱动的优势就非常明显了。

第三，配置驱动更容易做校验和提示。比如某个字段必填但你没填，工具可以在构建时直接报错，告诉你哪一条记录缺了什么。代码驱动的话，你可能要等到页面渲染出来才发现某个作品没显示，排查起来更麻烦。

当然，配置驱动也有代价。它牺牲了一部分灵活性——如果你想要一个非常特殊的布局，配置可能表达不出来。所以我在设计 artcraft 时，会保留一个“自定义扩展”的口子，允许在配置的基础上注入自定义的样式或脚本。这样既保证了大多数场景的易用性，又不会把路堵死。

2.2 模块划分与数据流向

artcraft 的模块划分我倾向于分成四层：数据层、逻辑层、渲染层、输出层。数据层负责读取和校验配置；逻辑层负责把配置转换成内部数据结构，并处理分类、排序、过滤等操作；渲染层负责把数据结构映射成具体的页面或组件；输出层负责生成最终的文件或部署到目标环境。

数据流向是单向的：配置 -> 校验 -> 转换 -> 渲染 -> 输出。这个单向性很重要，它意味着每一步的输入和输出都是确定的，出了问题可以快速定位是哪一层的问题。比如页面显示不对，你可以先检查配置是否正确，再检查转换后的数据结构是否符合预期，最后检查渲染模板有没有写错。如果数据流是双向的或者有循环依赖，排查起来就会非常痛苦。

我在实际项目中踩过一个坑：早期版本里，渲染层直接读取了原始配置，而不是转换后的数据结构。结果有一次配置里某个字段的类型写错了，渲染层没有报错，而是静默地显示了一个空值。后来我改成渲染层只接受转换后的数据，并且在转换层加了严格的类型校验，这个问题就再也没出现过。所以我的建议是：每一层只和相邻层打交道，不要跨层访问数据。

2.3 技术选型的取舍逻辑

artcraft 的技术选型，我会优先考虑“低依赖”和“跨平台”。低依赖意味着不需要安装一大堆东西才能跑起来，跨平台意味着在 Windows、macOS、Linux 上都能用。基于这两个原则，我倾向于用 Node.js 作为运行时，因为它在三个平台上都支持得很好，而且生态里有大量现成的工具可以用。

具体来说，配置文件的格式我选择 YAML 而不是 JSON。原因很简单：YAML 支持注释，写起来更像自然语言，对非技术用户更友好。JSON 虽然更严格，但不能写注释，而且括号和引号容易写错。我试过让一个没有编程背景的朋友用 JSON 写配置，他花了半小时才搞明白哪里少了一个逗号。换成 YAML 之后，他十分钟就写完了。

模板引擎我选择 Nunjucks 而不是 React 或 Vue。为什么？因为 artcraft 的定位是“生成静态内容”，不需要复杂的交互和状态管理。Nunjucks 的语法简单，学习成本低，而且渲染速度快。React 和 Vue 更适合做单页应用，对于作品展示这种场景来说有点杀鸡用牛刀。当然，如果你的作品需要复杂的交互，比如在线预览、拖拽排序，那 React 或 Vue 会更合适。但那是另一个项目了，artcraft 的核心场景还是“展示”和“管理”。

样式方案我选择原生 CSS 加 CSS 变量，而不是 Sass 或 Less。CSS 变量已经足够处理主题切换和响应式布局，而且浏览器原生支持，不需要编译步骤。Sass 和 Less 的功能更强大，但引入了额外的构建依赖。对于 artcraft 这种轻量工具来说，少一个依赖就少一个出问题的环节。

3. 核心细节解析与实操要点

3.1 配置文件的结构设计

配置文件是 artcraft 的入口，它的结构设计直接决定了用起来顺不顺手。我经过几次迭代，最终确定了一个三层结构：全局配置、分类配置、作品配置。

全局配置放在最上面，包括站点标题、描述、作者信息、主题色、字体等。这些是所有页面共享的。分类配置是一个列表，每个分类有名称、标识符、排序权重。作品配置也是一个列表，每个作品有标题、描述、封面图、所属分类、标签、外部链接等。

这里有一个细节：分类和作品之间通过标识符关联，而不是通过索引。为什么？因为索引会变。如果你在分类列表中间插入了一个新分类，后面所有作品的分类索引都会错位。用标识符关联的话，插入新分类不会影响已有作品。这个设计在作品数量多的时候尤其重要。

另一个细节是排序。我给每个分类和作品都加了一个order字段，数字越小越靠前。如果不填，就按添加顺序排列。这样既支持手动排序，又不会强制要求每个条目都填排序号。实际用下来，大部分创作者只会对少数几个重点作品手动排序，其他的保持默认顺序就好。

注意：YAML 对缩进非常敏感，必须用空格，不能用 Tab。我建议在编辑器里设置“Tab 转空格”，并且把缩进宽度设为 2 个空格。这样写出来的配置既紧凑又不容易出错。

3.2 素材管理的目录约定

artcraft 对素材的管理采用“约定优于配置”的原则。默认情况下，它会在项目根目录下找assets文件夹，里面再分images、videos、documents三个子文件夹。作品的封面图放在assets/images下，配置文件里只需要写文件名，不需要写完整路径。

这个约定的好处是，创作者不需要关心文件路径的拼接逻辑，只需要把文件放到正确的位置，然后在配置里引用文件名就行。如果某个项目的素材结构比较特殊，也可以在全局配置里覆盖默认路径。但我的经验是，90% 的场景用默认约定就够了，覆盖路径反而会增加理解成本。

还有一个细节：图片文件名我建议用英文或拼音，不要用中文或特殊字符。虽然现代操作系统和浏览器都支持中文文件名，但在某些部署环境下，中文文件名可能会导致路径解析问题。我遇到过好几次因为文件名里有空格或括号，导致图片加载失败的情况。后来统一改成小写英文加连字符，就再也没出过问题。

3.3 模板渲染的关键逻辑

模板渲染是 artcraft 的核心环节。它要做的事情是：读取转换后的数据结构，遍历分类和作品，生成对应的 HTML 片段，最后拼装成完整的页面。

这里的关键逻辑有两个：一是分类页和作品页的生成，二是首页的聚合展示。分类页需要列出该分类下的所有作品，作品页需要展示单个作品的详细信息，首页需要展示所有分类的入口和精选作品。

我在实现时用了一个技巧：把页面拆成“布局模板”和“内容模板”。布局模板负责页面的整体结构（头部、导航、底部），内容模板负责具体的内容区域。这样切换主题时只需要换布局模板，内容模板可以复用。这个拆分方式在后来换主题时省了我大量时间——我只改了一个布局文件，所有页面的风格就都变了。

另一个技巧是分页。如果作品数量超过 20 个，首页一次性加载所有作品会导致页面很长，加载也慢。所以我加了一个简单的分页逻辑：每页显示 12 个作品，通过 URL 参数控制页码。分页逻辑不复杂，但要注意边界情况——比如页码超出范围时应该显示最后一页，而不是报错。

3.4 输出与部署的实操步骤

artcraft 的输出是一个静态站点，包含 HTML、CSS、JavaScript 和素材文件。输出目录默认是dist，可以在全局配置里修改。

部署的步骤我一般是这样：先在本地运行构建命令，检查dist目录里的文件是否完整；然后用一个本地服务器预览一下，确认页面显示正常；最后把dist目录上传到静态托管服务。静态托管服务的选择很多，我倾向于用那些支持自定义域名和 HTTPS 的，具体选哪个看个人偏好和预算。

这里有一个实操心得：构建之前先清理dist目录。我早期版本没有清理，结果旧文件和新文件混在一起，有时候浏览器加载的是旧版本的 CSS，导致样式错乱。后来我在构建脚本里加了一行删除dist目录的命令，这个问题就解决了。虽然多花几秒钟，但省去了很多排查时间。

提示：如果你在本地预览时发现样式不对，先检查浏览器缓存。我遇到过好几次以为是代码问题，结果硬刷新一下就正常了。建议在开发阶段打开浏览器的“禁用缓存”选项。

4. 实操过程与核心环节实现

4.1 从零搭建 artcraft 项目的完整流程

假设你现在要从零开始搭建一个 artcraft 项目，我会按以下步骤来操作。整个过程大概需要 30 到 60 分钟，取决于你对命令行的熟悉程度。

第一步，创建项目目录。我习惯在用户目录下建一个projects文件夹，然后在里面建具体的项目文件夹。比如projects/my-artcraft。这个目录名我建议用英文，避免后续路径处理时出现编码问题。

第二步，初始化项目。打开终端，进入项目目录，运行npm init -y生成一个默认的package.json。然后安装依赖：npm install nunjucks js-yaml。这两个是核心依赖，一个负责模板渲染，一个负责解析 YAML 配置。如果你需要处理图片压缩，可以再加一个sharp，但这不是必须的。

第三步，创建目录结构。在项目根目录下创建config、templates、assets、src四个文件夹。config放配置文件，templates放模板文件，assets放素材，src放构建脚本。

第四步，编写配置文件。在config下创建site.yaml，写入全局配置和分类配置。然后在config下创建works.yaml，写入作品配置。刚开始可以先写两三个作品，方便测试。

第五步，编写模板。在templates下创建layout.njk、index.njk、category.njk、work.njk四个模板文件。layout.njk是基础布局，其他三个继承它。

第六步，编写构建脚本。在src下创建build.js，读取配置、校验数据、渲染模板、输出文件。这个脚本是 artcraft 的核心逻辑，我会在下一节详细说明。

第七步，运行构建。在终端运行node src/build.js，然后检查dist目录里是否生成了预期的文件。

第八步，本地预览。用npx serve dist或者任何静态服务器工具启动一个本地服务，在浏览器里打开对应的地址，检查页面显示是否正常。

4.2 构建脚本的核心代码解析

构建脚本是 artcraft 的发动机，它把配置和模板连接起来。下面是我常用的一个基础版本，你可以直接拿去改。

const fs = require('fs'); const path = require('path'); const yaml = require('js-yaml'); const nunjucks = require('nunjucks'); // 配置 nunjucks 模板引擎 nunjucks.configure('templates', { autoescape: true, noCache: true }); // 读取配置文件 function loadConfig() { const siteConfig = yaml.load( fs.readFileSync('config/site.yaml', 'utf8') ); const worksConfig = yaml.load( fs.readFileSync('config/works.yaml', 'utf8') ); return { site: siteConfig, works: worksConfig }; } // 校验配置 function validateConfig(config) { const errors = []; if (!config.site.title) { errors.push('缺少站点标题'); } config.works.forEach((work, index) => { if (!work.title) { errors.push(`第 ${index + 1} 个作品缺少标题`); } if (!work.category) { errors.push(`作品「${work.title}」缺少分类`); } }); if (errors.length > 0) { console.error('配置校验失败：'); errors.forEach(err => console.error(' - ' + err)); process.exit(1); } } // 按分类分组作品 function groupByCategory(works) { const groups = {}; works.forEach(work => { if (!groups[work.category]) { groups[work.category] = []; } groups[work.category].push(work); }); return groups; } // 渲染页面 function renderPages(config) { const { site, works } = config; const grouped = groupByCategory(works.works); // 渲染首页 const indexHtml = nunjucks.render('index.njk', { site: site, categories: works.categories, grouped: grouped }); fs.writeFileSync('dist/index.html', indexHtml); // 渲染分类页 works.categories.forEach(cat => { const catHtml = nunjucks.render('category.njk', { site: site, category: cat, works: grouped[cat.id] || [] }); fs.writeFileSync(`dist/category-${cat.id}.html`, catHtml); }); // 渲染作品页 works.works.forEach(work => { const workHtml = nunjucks.render('work.njk', { site: site, work: work }); fs.writeFileSync(`dist/work-${work.id}.html`, workHtml); }); } // 主流程 function build() { console.log('开始构建...'); const config = loadConfig(); validateConfig(config); renderPages(config); console.log('构建完成，输出目录：dist'); } build();

这段代码的逻辑很直白：读配置、校验、分组、渲染、写文件。我特意把每个步骤拆成独立的函数，方便单独测试和修改。比如你想加一个“标签页”的生成逻辑，只需要在renderPages里加一段循环就行，不需要动其他部分。

有一个细节值得注意：validateConfig函数在发现错误时会直接退出进程，并且打印出所有错误。这样做的好处是，创作者可以一次性看到所有问题，而不是修一个报一个。我试过让一个朋友用这个工具，他第一次配置时漏了三个作品的分类，如果只报第一个错误，他可能要来回改三次。一次性报出来，他一次就改完了。

4.3 模板文件的关键写法

模板文件决定了最终页面的样子。下面是一个简化的layout.njk，你可以在此基础上扩展。

<!DOCTYPE html> <html lang="zh-CN"> <head> <meta charset="UTF-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <title>{{ site.title }}</title> <link rel="stylesheet" href="/assets/style.css"> </head> <body> <header> <h1><a href="/">{{ site.title }}</a></h1> <p>{{ site.description }}</p> </header> <nav> {% for cat in categories %} <a href="/category-{{ cat.id }}.html">{{ cat.name }}</a> {% endfor %} </nav> <main> {% block content %}{% endblock %} </main> <footer> <p>{{ site.author }} · {{ site.year }}</p> </footer> </body> </html>

这个布局模板定义了页面的骨架，{% block content %}是留给子模板填充的区域。index.njk、category.njk、work.njk都继承这个布局，只需要实现自己的内容块。

index.njk的内容大概是这样的：

{% extends "layout.njk" %} {% block content %} {% for cat in categories %} <section> <h2>{{ cat.name }}</h2> <div class="work-grid"> {% for work in grouped[cat.id] %} <article class="work-card"> <img src="/assets/images/{{ work.cover }}" alt="{{ work.title }}"> <h3><a href="/work-{{ work.id }}.html">{{ work.title }}</a></h3> <p>{{ work.description }}</p> </article> {% endfor %} </div> </section> {% endfor %} {% endblock %}

这个模板遍历所有分类，每个分类下再遍历作品，生成一个卡片网格。work.cover是封面图的文件名，work.title是作品标题，work.description是描述。这些字段都来自配置文件。

注意：模板里的路径我用了绝对路径（以/开头），这样在子页面里引用素材时不会出现相对路径错乱的问题。如果你要把站点部署到子目录下，需要把绝对路径改成带子目录前缀的路径，或者在构建时动态生成。

4.4 样式与响应式布局的实现

artcraft 的样式方案我选择原生 CSS 加 CSS 变量。下面是一个基础的样式文件，包含了主题色定义和响应式网格。

:root { --color-primary: #2c3e50; --color-accent: #e74c3c; --color-bg: #fafafa; --color-text: #333; --font-main: -apple-system, BlinkMacSystemFont, "Segoe UI", sans-serif; --spacing-unit: 1rem; --max-width: 1200px; } * { box-sizing: border-box; margin: 0; padding: 0; } body { font-family: var(--font-main); background: var(--color-bg); color: var(--color-text); line-height: 1.6; } header, nav, main, footer { max-width: var(--max-width); margin: 0 auto; padding: var(--spacing-unit); } .work-grid { display: grid; grid-template-columns: repeat(auto-fill, minmax(280px, 1fr)); gap: var(--spacing-unit); } .work-card { background: #fff; border-radius: 8px; overflow: hidden; box-shadow: 0 2px 8px rgba(0,0,0,0.08); transition: transform 0.2s; } .work-card:hover { transform: translateY(-4px); } .work-card img { width: 100%; height: 200px; object-fit: cover; } .work-card h3, .work-card p { padding: 0 var(--spacing-unit); } .work-card h3 { margin-top: var(--spacing-unit); } .work-card p { margin-bottom: var(--spacing-unit); color: #666; }

这段样式的核心是grid-template-columns: repeat(auto-fill, minmax(280px, 1fr))。这行代码的意思是：自动填充列，每列最小 280 像素，最大 1 份剩余空间。效果是，在宽屏上显示多列，在窄屏上自动变成单列，不需要写媒体查询。我试过在手机、平板、桌面显示器上预览，布局都能自适应，省去了手动调断点的麻烦。

CSS 变量的好处是，换主题只需要改:root里的几个颜色值。比如把--color-primary从深蓝改成墨绿，整个站点的标题和导航颜色就都变了。这个设计在给不同客户做定制时特别有用，改一个地方就能出不同风格的版本。

5. 常见问题与排查技巧实录

5.1 配置解析失败的典型原因

YAML 配置解析失败是最常见的问题，我整理了一个速查表，覆盖了 90% 的情况。

我踩过最坑的一次是，配置里有一个作品的描述包含了一个冒号，结果 YAML 把冒号后面的内容当成了新的键值对，导致整个作品数据错乱。后来我养成了一个习惯：凡是包含特殊字符的字段，一律用双引号包起来。虽然多打两个字符，但省去了排查时间。

5.2 页面显示异常的排查思路

页面显示异常通常有三类：样式不对、内容缺失、链接失效。我的排查顺序是：先看控制台有没有报错，再看网络面板有没有资源加载失败，最后检查生成的 HTML 结构是否符合预期。

样式不对的话，先确认 CSS 文件是否被正确加载。我遇到过好几次是因为dist目录里没有生成 CSS 文件，原因是构建脚本里忘了复制assets目录。后来我在构建脚本里加了一步fs.cpSync('assets', 'dist/assets', { recursive: true })，确保素材和样式文件都会被复制过去。

内容缺失的话，先检查配置文件里对应的字段有没有填。如果填了但没显示，检查模板里的变量名是否和配置里的字段名一致。Nunjucks 对变量名是大小写敏感的，work.Title和work.title是两个不同的变量。我建议在模板里统一用小写加下划线的命名风格，和配置保持一致。

链接失效的话，检查生成的 HTML 文件路径和链接地址是否匹配。比如分类页生成的是category-design.html，但导航里的链接写的是category-design，少了.html后缀，就会 404。我建议在构建脚本里统一生成链接，而不是在模板里手写，这样可以避免拼写错误。

5.3 构建速度优化的实操经验

当作品数量超过 100 个时，构建速度会明显变慢。我实测下来，100 个作品大概需要 3 到 5 秒，500 个作品可能需要 15 秒以上。虽然不算太慢，但每次改一点东西都要等十几秒，体验不太好。

我用了两个优化手段。第一个是缓存模板编译结果。Nunjucks 默认每次渲染都会重新编译模板，如果模板文件没变，编译结果可以复用。我在构建脚本里加了一个简单的缓存机制：用文件的修改时间作为缓存键，如果模板文件没变，就直接用上次编译的结果。这个优化大概能减少 30% 的构建时间。

第二个是并行渲染。Node.js 是单线程的，但渲染每个页面是独立的操作，可以用Promise.all并行执行。我把renderPages函数改成了异步版本，每个页面的渲染包在一个 Promise 里，最后统一等待。这个优化在页面数量多的时候效果很明显，500 个页面的渲染时间从 15 秒降到了 6 秒左右。

提示：并行渲染时要注意文件写入的冲突。如果两个页面同时写入同一个文件，可能会导致内容错乱。我的做法是确保每个页面的输出文件名是唯一的，这样就不会有冲突。

5.4 部署后的常见问题与应对

部署到静态托管服务后，最常见的问题是路径问题。本地预览时用的是相对路径，部署后可能变成绝对路径，或者反过来。我建议在构建时就统一用绝对路径，并且在本地预览时也用绝对路径测试，确保两边一致。

另一个问题是缓存。静态托管服务通常会缓存 HTML、CSS、JS 文件，更新后用户可能看到的是旧版本。解决方法是在文件名里加哈希值，比如style.a1b2c3.css，这样每次构建生成的文件名都不同，浏览器会自动加载新文件。这个方案需要在构建脚本里加一步计算文件哈希并重命名的逻辑，稍微复杂一点，但效果很好。

还有一个问题是 HTTPS 和自定义域名。大部分静态托管服务都支持自动 HTTPS，但自定义域名需要配置 DNS 解析。我建议在部署前先确认域名解析是否正确，可以用dig或nslookup命令检查。如果解析不对，页面会打不开，而且报错信息可能不太直观。

6. 扩展方向与个人实践体会

artcraft 这个项目本身不复杂，但它的扩展空间很大。我在实际使用中尝试过几个方向，这里分享一下。

第一个扩展方向是加一个简单的后台管理界面。不需要很复杂，一个表单页面，可以添加、编辑、删除作品，数据保存到本地文件或者轻量数据库。这样创作者就不需要手动编辑 YAML 文件了，对非技术用户更友好。我用了一个周末做了一个原型，核心逻辑就是读取 YAML、渲染表单、提交后写回 YAML。虽然简陋，但用起来比手动编辑配置文件方便多了。

第二个扩展方向是支持多语言。如果作品需要同时展示中文和英文，可以在配置里加一个locale字段，然后根据用户的语言偏好渲染不同的内容。这个功能对于面向国际市场的创作者很有用。实现上就是在模板里加一个语言判断，根据当前语言选择对应的字段。

第三个扩展方向是集成图片处理。artcraft 目前只是引用图片，不做任何处理。如果能在构建时自动压缩图片、生成缩略图、转换格式，会省去很多手动操作。我用sharp库试过，效果不错，但增加了安装依赖的复杂度。如果你的项目对图片质量要求高，这个扩展值得做。

我个人在实际操作中的体会是，工具的价值不在于功能多，而在于是否真正融入了工作流。我见过太多人花大量时间折腾工具，结果内容本身没做多少。artcraft 的设计初衷就是让创作者把时间花在内容上，工具本身应该尽量透明、无感。所以我在做这个项目时，一直提醒自己：能自动化的就自动化，不能自动化的就简化，简化不了的就提供清晰的文档和报错信息。

最后再分享一个小技巧：在配置文件里加一个draft字段，标记哪些作品是草稿。构建时可以选择是否包含草稿。这样你在创作过程中可以随时保存进度，不用担心半成品被发布出去。这个字段实现起来很简单，在分组和渲染时过滤一下就行，但用起来非常顺手。