用了两年多那套开源博客系统最让我崩溃的不是写文章本身而是发文章时加标签的体验。你记得自己三个月前写过一篇关于 JavaScript 闭包的文章现在想给新文章也打上JavaScript标签于是你在标签输入框里敲了一个java结果系统告诉我没有匹配项——因为它做的是全等匹配你得一个字母不差地把整串名字敲完敲到JavaScript才肯认账。更扯的是就算你敲完了它也不给你下拉建议你得自己翻标签列表一页一页找找到眼花。那段时间我一度怀疑自己是不是在用 2005 年的系统后台。后来我终于忍不住拉上几个同事把这个发帖时的标签搜索彻底重做了一遍。这篇文章就把整个改进过程从头到尾拆给你看包括问题到底出在哪、交互应该怎么设计、前后端怎么实现、还有我们踩过的那些坑。如果你也在维护博客、CMS 或任何带标签功能的社区产品这篇应该能帮你少走不少弯路。1. 发帖时标签搜索的现状三个让人抓狂的典型问题动手改之前我们先把老系统翻了个底朝天。不翻不知道一翻才发现标签搜索难用是多种问题叠加的结果。很多产品都是这么一步步烂掉的起初觉得能用就行等用户习惯被养成了再改就要付出更大的代价。1.1 全等匹配设计上最省事体验上最致命老系统的搜索逻辑极其简单直接前端拿到输入框的值拼进一个WHERE name ?的 SQL 查询里查得到就返回查不到就提示标签不存在。这个设计如果在标签总量只有几十个、且所有用户都遵守同一套命名规范的系统里勉强跑得通。但一旦标签到了几百上千个问题就暴露了。最直接的恶果是用户根本不知道系统到底存了哪些标签。你输入React查不到也许系统里存的是react也许是React.js也许reactjs。你猜不中准确拼写就永远匹配不上这个标签。于是用户的选择只剩下两条要么去标签管理页翻那几页列表要么干脆重新创建一个新标签。大部分人选了后者因为翻列表太累了。这就是重复标签几何级增长的温床。我后来统计了自己维护的那个站点的标签表2200 多个标签里粗略估算有 300 多个是重复或者近似重复的。最典型的就是大小写不一致java和Java各来一个中英文混用前端和Web前端并存还有单复数混用tag和tags同时存在。这些标签你从管理后台看觉得用户怎么这么懒、这么粗心实际上根子就在这个全等匹配的搜索逻辑上——它从设计上就逼着用户重复造轮子。1.2 排序缺失你搜出来的结果没有任何参考价值老系统的查询走完过滤之后排序规则是ORDER BY name ASC纯按首字母排。这就带来一个很尴尬的场景你想找一个叫PHP的标签但它可能排在PhpDocumentor后面因为按字典序PhpDocumentor的第五个字符是D而PHP第三个字符就结束了在普通字符排序规则下短字符串会被排在长字符串之后。结果你输入一个 php看到的结果列表把冷门得几乎没人用的长标签放在最前面真正应该靠前的老标签反而藏在后头。排序没有热度和新鲜度的概念是标签体系持续劣化的第二个结构性原因。一个帖子永远只能认领它第一次匹配上的那个标签用户没耐心找就随手新建一个而新建的标签又因为首字母排序规则混在一堆同类标签里跟老标签享受同等曝光。新标签没有额外权重老标签也没有因为长期使用而变得更容易被搜索到。整个系统就像一个从不打扫的房间东西只会越来越多、越来越乱而清扫成本也在不断增加。1.3 交互反馈缺失输入框就像一个黑洞老系统的交互是这样的你输入关键字点一个搜索按钮页面跳转到搜索结果页结果显示一堆模糊的、被你猜不透的标签。没有自动补全没有即时下拉没有最近使用没有键盘操作。你想选一个标签只能在搜索结果页和编辑页之间反复跳转。这个设计放在十年前的交互标准下也许不算太差但现在用户早就被各种现代产品教育过了输入框应该即时给出建议列表应该支持键盘上下选择按回车就能选中输入太快时系统应该自动防抖而不是丢请求……这些都已经成为基础体验的一部分。老系统一样都没有。我印象最深的一个用户吐槽是我就想给我的文章加个标签结果我把写文章的时间的一半花在了找标签上。这话虽然夸张但确实反映了当时的处境。2. 目标体验一个合格的标签搜索组件应该具备的四个特征在动手开发之前我们内部专门开了一次需求对齐会。可能很多团队会觉得这种小功能还开什么会直接写不就完了但正是这种小功能不值得设计的心态才会导致前面说的那些问题反复出现。我们把目标体验拆成了四个维度匹配方式、排序策略、交互形态、性能底线。每个维度都定了明确的验收标准。2.1 匹配方式从等于升级为包含核心改动是把数据库查询从WHERE name ?改成WHERE name LIKE %keyword%。这个改动表面上是一行 SQL 的差别实质上是把用户从必须记住标签全名的负担中解放了出来。你输入java现在能同时命中Java、JavaScript、JavaWeb、Head First Java等一串标签用户只要记得大概的长相就够了。需要注意这只是一个底限。如果只做包含不做排序和交互你只是把用户从找不到变成了找到一堆不知道选哪个。所以匹配方式必须和排序策略搭配使用。2.2 排序策略把用户最可能想用的放到最前面我们最初设计的排序公式很直白score 使用次数 × 0.6 最近使用时间 × 0.3 匹配位置权重 × 0.1 - 名称长度 × 0.05。解释一下每个项的动机。使用次数代表这个标签的总热度一个被用过 500 次的标签大概率比被用过 3 次的标签更值得被优先展示。但只有热度远远不够因为有些标签在几年前很火、如今早已没落放在第一位只会干扰现在的用户。于是我们引入了最近使用时间——距离现在越近、被使用过的标签权重越高。匹配位置权重则用来区分JavaScript和Head First JavaScript在搜java时的差异前者是开头匹配更接近用户意图后者是中间匹配排序上应该靠后。名称长度惩罚项是为了防止某些小长度标签在冷门匹配时意外占便宜这个参数在真实数据里需要不断微调。最终我们验证下来用真实用户查询日志回放排序结果新的排序策略在前 5 条命中率比原来按首字母排序提高了接近 40 个百分点。当然这个数字跟数据和查询分布有关但你至少能看到排序不是小事它对用户能不能快速找到想要的东西有决定性的影响。2.3 交互形态键入即搜键盘可操作一个标签搜索框本质上是用户和标签库之间的对话。好的对话应该是实时应答的而不是你敲半天才给你回应。所以交互形态的底线是用户输入超过一个字符系统就要给出候选列表候选列表位置要足够稳定不能一闪而过鼠标能点键盘也能操作。具体交互流程上我们参考了现代前端里比较成熟的 combobox 交互模式输入关键字防抖 150ms 后发起搜索搜索结果显示在下拉框中每个候选标签显示名称、使用次数和最近使用时间使用上下方向键移动高亮项回车键选中当前高亮项按 Esc 收起下拉框输入内容没有任何匹配时显示创建标签 xxx的兜底选项但会提示这是新标签。这套交互对用户来说几乎没有学习成本因为绝大多数人都在 GitHub、Twitter、Notion 里见过类似的设计。我们做的只是把业界成熟模式搬到了自己的系统里。2.4 性能底线大数据量下依然秒开我们站点的标签规模已经接近 1 万而一些头部社区动辄十几万甚至更多。性能如果没有底线交互做得再好也是白搭。我们定的目标参考标准是在标签表 10 万条记录规模下接口查询耗时 P95 低于 100ms。这个数字不激进但能满足实际使用的流畅感。为了达到这个目标我们后面在索引和缓存上做了不少文章具体的实现细节放在第 4 章和第 5 章讲。这里先明确一点性能必须在设计阶段就进入约束条件而不是等功能开发完再去优化。3. 前端交互实现自动补全下拉框的完整方案需求定义清楚之后进入前端实现阶段。这个功能放在现代前端工程里已经是一个高度成熟的模式但成熟不等于好抄。我们最终没有引入现成的 UI 组件库而是自己封装了一个大约 200 行的组合式组件。原因后面细说。3.1 组件选型直接手写不依赖第三方库市面上不少组件库都提供带 filterable 标签搜索功能的下拉选择器。你完全可以引入一个现成的 Select 组件配上远程搜索方法十来行代码就能跑起来。但我们的实际场景要求三个定制点现成组件反而别扭。第一结果展示结构要包含使用次数、最近使用时间这些信息大部分 Select 组件只支持单行文本展示定制起来很费劲。第二需要创建新标签的兜底逻辑这个逻辑要和搜索结果混在同一个列表里展示。第三我们需要精细地控制键盘导航行为特别是在移动端以及和浏览器默认行为冲突的场景下自己实现反而更可控。所以最终方案是自己写一个轻量组件。核心逻辑拆成四个模块输入框 下拉容器、请求调度、键盘导航、渲染逻辑。3.2 输入到渲染的完整链路防抖、竞态与高亮先说防抖。我们使用的是 150ms 的防抖阈值这来自一个朴素的观察大部分人类用户正常输入一个字符的间隔在 100ms 到 300ms 之间150ms 能较好平衡响应速度和不必要的请求数量。如果你设置 300ms用户会明显感到拖沓如果你设置 50ms又会在输入停顿的间隙发出大量无用请求。这里每个团队可以根据自己的场景微调但原则是不变的既要快又不能滥用请求。防抖实现我直接给出一个最简洁的版本let debounceTimer null; function onSearchInput(value) { clearTimeout(debounceTimer); debounceTimer setTimeout(() { fetchTagSuggestions(value); }, 150); }防抖只解决了请求发太多的问题但没解决请求返回顺序错乱的问题。假如用户先输入java停顿 150ms发出请求 A再输入javas停顿 150ms发出请求 B。如果请求 A 因为某种原因比请求 B 晚返回那么界面上显示的就是过期的java结果。这就是经典的竞态问题。我见过不少团队在这里踩坑解决方式通常是给请求加序号标记或者直接用AbortController取消过期请求。我们用了序号方式最简单直观let requestSeq 0; async function fetchTagSuggestions(keyword) { const currentSeq requestSeq; const result await api.searchTags(keyword); if (currentSeq requestSeq) { renderSuggestions(result); } }再说渲染。每个候选标签的展示结构我们最终定下来是标签名称、使用次数用一个小徽标展示、最近使用时间灰色文字展示。如果搜索结果只有名称没有元数据用户依然要做判断体验提升有限。具体到高亮匹配片段我们只推荐用textContent操作不要直接拼接innerHTML否则一旦标签名里包含、、这类字符就存在被注入脚本的风险。你可以自己写一个高亮函数用正则把keyword匹配到的子串包在strong标签里然后通过innerHTML赋值前对原字符串做转义安全第一。3.3 键盘导航从 0 到 N 的状态管理键盘导航是这类组件最容易做糙的地方因为它在 UI 上不明显代码里却需要维护一个activeIndex状态。整体逻辑是维护一个activeIndex变量初始为 -1监听输入框的 keydown 事件按 ArrowDown若activeIndex items.length - 1则activeIndex按 ArrowUp若activeIndex 0则activeIndex--按 Enter如果activeIndex不为 -1则选中对应标签否则触发创建新标签逻辑按 Escape收起下拉框并把activeIndex重置为 -1。这里有一个很容易被忽略的细节当activeIndex变化时最好把当前高亮项滚动到可视区域内否则用户用键盘选到列表底部时屏幕上根本看不见高亮项。另外按回车时一定要阻止默认行为因为input在 form 里的默认行为是提交表单如果不拦就会触发页面刷新或表单提交非常裂开。你的代码大概长这样function handleKeydown(e) { if (e.key ArrowDown) { e.preventDefault(); setActiveIndex((old) Math.min(old 1, items.length - 1)); } else if (e.key ArrowUp) { e.preventDefault(); setActiveIndex((old) Math.max(old - 1, -1)); } else if (e.key Enter) { e.preventDefault(); if (activeIndex 0) { selectTag(items[activeIndex]); } else { createNewTag(inputValue); } } else if (e.key Escape) { setOpen(false); setActiveIndex(-1); } }3.4 创建新标签兜底逻辑防止重复要从输入框开始防标签搜索的一个隐藏价值是防止重复。所以当用户输入的内容没有任何匹配时我们不能只是冷冰冰地显示无结果而要把没有结果转化为你可以创建一个新标签的行为引导。但这里有个细节并不是所有输入都适合直接创建标签。例如包含空格的长字符串、带有#和的字符串、纯数字串这些在大多数标签系统里都是不合规的。我们在前端做的校验规则是去除首尾空白后长度在 1 到 30 个字符之间不能包含空白字符不能包含#、、/、\、,这些特殊字符。如果通过校验就显示创建标签 xxx点击后走创建流程并且创建前再次向后端发送一个是否存在的校验请求避免因为并发导致重复创建——这个后端并发问题我在第 6 章再展开。4. 后端搜索逻辑与索引设计从慢查询到毫秒级响应前端交互只解决了看起来好用的问题真正决定用起来爽不爽的是后端的查询能力和数据模型。这一章把后端设计拆开揉碎讲。4.1 数据模型给标签表加上热度字段老系统的tags表只有三个字段id、name、created_at。只靠这三个字段你连最热标签都排不出来。我们最终改造后的表结构如下字段类型说明idint / bigint主键namevarchar(50)标签名称加唯一索引slugvarchar(60)用于 URL 的转写形式可空post_countint使用次数发布文章时同步累加last_used_atdatetime最近一次被使用的时间created_atdatetime创建时间post_count和last_used_at是关键的新增字段。它们的更新时机是每次给文章成功打上标签时执行一条 UPDATE把对应标签的post_count加一last_used_at更新为当前时间。这个操作放在文章发布的事务里开销极小但能保证排序数据始终是最新的。4.2 SQL 查询的进化LIKE、索引失效与 pg_trgm我们的技术栈是 PostgreSQL所以接下来以 PG 为例讲索引设计但思路在 MySQL 上同样适用。最初我们直接用WHERE name LIKE %keyword%在标签表只有几百条时没有任何问题。但当我们把数据量压到 10 万条时问题立刻暴露了普通的WHERE name LIKE %keyword%无法走 B-Tree 索引它会把全表扫一遍。我实测在普通笔记本上10 万条标签的LIKE %java%查询耗时约 1.6 秒。这是完全不可接受的。可能有人会问为什么LIKE %keyword%不能走 B-Tree 索引这要从 B-Tree 索引的数据结构说起。B-Tree 索引按索引列的值有序排列可以用来高效匹配前缀比如LIKE java%就可以走索引因为索引能快速定位到所有以java开头的记录。但LIKE %java%要求的是字符串任意位置包含关键字数据库在 B-Tree 里没法直接定位只能遍历所有记录逐条匹配这就退化成了全表扫描。解决方案有几种。MySQL 可以用全文索引Fulltext Index但 MySQL 的全文索引默认是按空格分词对中英文混合标签的支持不算理想。PostgreSQL 这边我们选的是pg_trgm扩展方案。它把字符串拆成连续三个字符的片段trigram然后建 GIN 索引这样LIKE %keyword%就能走索引在 10 万条数据的场景下查询耗时会降到 10 到 30 毫秒完全满足我们的性能目标。具体做法是CREATE EXTENSION IF NOT EXISTS pg_trgm; CREATE INDEX index_tags_name_trgm ON tags USING gin (name gin_trgm_ops);这行命令执行完之后原来的LIKE %keyword%查询就不需要改代码查询计划会自动切换到索引扫描。需要注意的是pg_trgm对中文的支持一般因为中文不像英文那样天然按字母拆词trigram 对中文按字符拆会有噪声但实际测试下来对于标签这种短文本场景中文标签的模糊匹配依然可以接受相比全表扫描的提升依然非常明显。4.3 排序公式落地应用层打分比纯 SQL 更灵活第 2 章提到的排序公式我们最终没有完全写进 SQL而是采用SQL 取 TOP 50 应用层精排的混合策略。为什么这么拆因为 SQL 里写一堆复杂的加权公式维护起来很痛苦而且标签数据量本身不算大先把候选缩小到 50 条再在应用层做精确打分性能完全够用代码可读性也会好很多。先看 SQL 部分SELECT id, name, post_count, last_used_at FROM tags WHERE name ILIKE % || $1 || % ORDER BY post_count DESC, last_used_at DESC LIMIT 50;ILIKE是 PostgreSQL 里不区分大小写的模糊匹配这能解决用户输入java却想匹配Java的问题。ORDER BY post_count DESC, last_used_at DESC先按热度粗排让热门标签一定出现在候选集里。应用层的精排则把匹配位置、名称长度、新鲜度等因子加权进去function scoreTag(tag, keyword) { const idx tag.name.toLowerCase().indexOf(keyword.toLowerCase()); const positionWeight idx 0 ? 10 : idx 0 ? 5 : 0; const freshness Math.max(0, 1 - (Date.now() - tag.last_used_at) / (30 * 24 * 3600 * 1000)); return tag.post_count * 1.0 positionWeight freshness * 5 - tag.name.length * 0.1; }这个打分函数兼顾了使用次数多、匹配位置靠前、最近有被使用、名称短四个维度。实际投放以后我们反复调整过几个权重参数最终让排序结果尽量贴近用户直觉。这里有个经验这类权重没有银弹需要拿真实搜索日志反复验证权重调参本身也是优化的一部分。4.4 API 设计轻量、可缓存、语义清晰搜索接口我们设计得很简单核心是给前端足够的信息去渲染下拉框GET /api/v1/tags/suggest?qjavalimit10 响应: { data: [ { id: 1, name: Java, slug: java, post_count: 235, last_used_at: 2024-11-03T12:00:00Z } ] }在设计上有两个额外的细节。第一响应头加上Cache-Control: max-age60因为标签库的变化频率本身很低客户端缓存一分钟对正确性几乎没有影响但能显著减少无效请求。第二如果q参数为空不返回通用列表而是返回当前用户最近使用的标签配合前端在输入框聚焦时展示最近使用的标签能进一步提升发帖效率。5. 性能实测与边界情况10万条标签下的验证功能开发完后我们做了专门的压测和边界验证。没有这层验证很多事情只有上了生产才发现那就有点晚了。5.1 测试环境与数据准备测试机就是一台普通的公司开发笔记本8 核 CPU 加 16GB 内存PostgreSQL 14 跑在 Docker 里。我们用脚本往标签表里灌了 10 万条数据尽量模拟真实的标签命名分布英文、中文、中英混合都有。5.2 各方案耗时对比直接给数据查询方案10 万条数据耗时无索引LIKE %keyword%约 1600ms普通 B-Tree 索引 LIKE %keyword%约 1500ms索引未命中依旧全表扫描pg_trgmGIN 索引 LIKE %keyword%约 15-40mspg_trgmGIN 索引 LIKE 排序 LIMIT 10约 25-60mspg_trgm的提升是数量级的。而且能看到一个关键现象即使加了 GIN 索引如果查询涉及ORDER BY post_count DESC且结果集很大排序本身还是要花不少时间所以要加 LIMIT让数据库先裁掉大部分行再排序。这个顺序务必理解清楚——让数据库在尽可能早的阶段减少返回行数是性能优化的重中之重。5.3 边界情况大小写、特殊字符、中文标签第一个边界是大小写。用户输入java能不能命中Java、JAVA我们使用了ILIKE在 PG 里直接解决。如果你用的是 MySQL可以用LOWER(name) LIKE LOWER(%keyword%)但要注意给LOWER(name)建函数索引否则又回退到全表扫描。第二个边界是特殊字符。用户输入#前端或前端带空格这类输入几乎不可能匹配到任何合法标签。我们选择在前端直接拦截不发起请求避免后端被无意义的查询轰炸。后端的过滤规则也保留一份防止有人绕过前端直接调接口。第三个边界是中文标签。中文搜索和英文有一个非常大的区别英文单词天然有空格分隔用户输入java能比较准确地表示一个完整语义中文则不一样用户输入前可能想匹配前端也可能想匹配前端的那些事。而pg_trgm对中文按字符拆 trigram效果不如对英文那么精准但标签这种短文本内容足够短实际验证下来中文标签的模糊匹配结果基本可用。更大的问题还是在排序——只输入一个字的时候匹配到的标签可能非常多这时排序权重的作用会被放大所以我们的精排逻辑对中文场景要格外关注。5.4 缓存策略让最近使用的标签变得真正可用除了pg_trgm索引我们还加了内存缓存。标签列表整体变化频率低实时性要求也不高所以缓存收益非常大。我们用的策略非常简单标签搜索接口结果缓存 5 分钟标签被创建或被使用时主动失效相关缓存缓存命中时搜索直接在缓存数据里做子串匹配和排序连数据库都不用打。实际验证下来缓存命中时接口耗时只有几毫秒对用户体验的提升是很明显的。但缓存也不是没有坑后面第 6 章会讲一个因为缓存引发的假搜不到问题。6. 开发过程中踩过的几个坑完整排查链路最后讲讲这个功能从开发到上线的过程中我们踩过且有一定代表性的几个坑。这些问题在文档里基本找不到现成答案只能靠实际调试和排查。6.1 防抖时间与手机性能的错位最开始我们定的防抖时间是 200ms在桌面浏览器上完全没问题。但部署到线上后有用户反馈在安卓手机上输入时搜索跟不上打字速度。排查链路是这样的先怀疑接口变慢但后端监控显示接口响应都在 50ms 内再怀疑网络问题但同样的网络条件下 iPhone 又是好的最后用 Chrome DevTools 模拟中低端安卓机性能发现 200ms 防抖中已经包含了输入法组合阶段的停顿用户在输入法中选字的过程被计算到了防抖时间内导致每次搜索都延迟 150ms 以上。最终的解决办法不是调防抖时间而是监听compositionend事件来区分拼音/中文输入法的组合过程。在组合期间不触发搜索只在compositionend后执行一次搜索。这一改中英文输入都顺畅了。6.2 快速输入时的竞态老响应覆盖新响应这个问题在第 3 章提过但我再展开一下完整排查过程。测试阶段我们就发现快速输入vue然后清空再输入react偶尔会出现结果列表还是vue的候选。第一次排查时以为是防抖没生效后来打了 log 发现两个请求都发出去了而且vue的请求比react的请求晚返回。原因是一个老接口响应慢另一个新接口响应快DOM 被后返回的旧数据覆盖了。我们的修复方式用的是请求序号比对代码在第 3 章给出了。这个方案比用AbortController更轻量也不需要处理 abort 相关的兼容性问题。如果你工程里已经用了现代 fetch两个方案都可以核心是不要在这个问题上裸奔。6.3 回车键与表单默认提交的冲突这是一个很小的坑但破坏性极大。我们的发帖页面是一个大表单标签输入框在表单内部。用户在下拉框里按回车想选中标签结果整个表单被提交了页面刷新文章内容还没保存用户直接傻眼。排查链路打开控制台看了 Network发现按下回车瞬间触发了一个 POST 请求到表单的 action 地址而且 DOM 上出现了 form validation 的提示。原因就是没有对键盘事件调用preventDefault()浏览器把回车当成了提交表单。修复方式就是在 Enter 分支里统一调用e.preventDefault()。这个问题如果你不主动拦截100% 会踩到。6.4 并发创建重复标签唯一索引与异常捕获上线后第二周我们发现标签表里出现了两个一模一样的Node.js查了创建时间前后只差 0.3 秒。这说明两个用户同时在搜索Node.js都没搜到已有记录于是同时点击了创建标签两个 INSERT 都成功了。排查发现这个 bug 的根因有两个层面。第一应用层只做了搜索存在性校验但搜索和创建不是原子操作中间隔着一个网络往返。第二数据库层面没有加唯一索引进约束。修复方案也很直接tags.name字段加唯一索引然后应用层捕获唯一约束冲突的错误如果 INSERT 时发现已存在同名字段就把返回结果替换成已有标签。有了这道兜底并发重复创建的问题彻底解掉了。6.5 标签名里的 HTML高亮不等于可以执行最后这个坑和安全相关。在做高亮功能时第一版实现直接用了innerHTML去拼接高亮后的字符串结果测试工程师输入了一个/spanscriptalert(1)/script的标签名下拉框渲染后直接把脚本执行了。这是一个典型的存储型 XSS 漏洞。排查后修复的方式是三管齐下后端在创建标签时对名称做白名单校验拒绝包含、、等字符的标签名前端渲染高亮片段时先做 HTML 转义再插入strong标签前端组件统一使用textContent作为兜底。这套组合下来安全风险才算真正降下去。回过头来看这个标签搜索功能从需求提出到上线大概用了三个迭代周期。核心改动并不复杂但前面老系统积累的债不少需要一次性还清。上线后我特意观察过用户的发帖行为最大的变化是新建标签的比例明显下降了更多人开始复用已有标签标签体系进入了一个正向循环。当初被吐槽加个标签比写文章还累的声音也基本消失了。如果你也在维护类似的功能我的建议很朴素搜索不是功能搜索是体验的地基。今天多花一点时间把地基打牢以后维护标签体系会轻松很多。