企业官网建设流程全解析

上周帮后端同事排查一个接口报错，他把报错贴过来的时候我人都看愣了：failed to deserialize the json body into the target type: input: missing field。这种问题有个特点，报错本身等于没说，真正的病根全藏在请求体的JSON结构里。他习惯性想去找在线格式化网站，翻了半天书签，公司内网环境下外网工具一个都打不开。最后我直接盘了一个Vue3的小工具页面，把那段JSON贴进去，格式化完一眼就看出是userProfile里缺了nickname字段，问题当场解决。

这次之后我就认真把这件事做了全套：一个完整可用的JSON格式化工具，以模块化组件的形式嵌进了后台管理系统。今天这篇文章不聊什么高深架构，就把这个工具在Vue3项目里的完整实现拆开讲清楚：格式化引擎怎么写、语法高亮怎么做、错误提示怎么做到位、大JSON卡顿怎么优化，以及在真实项目里落地会遇到哪些文档里不会写的坑。无论你是在做后台管理系统、调试工具集，还是单纯想把JSON处理能力沉淀到团队的工具链里，这篇都应该对你有用。

1. 为什么要把格式化能力做进自己的Vue3项目

1.1 在线工具的三大痛点

先说动机，没有动机后面全是空谈。很多人觉得"用在线工具不就行了，何必自己造轮子"，但这个想法在你写下第一行代码之前，就已经被实际场景打脸了。

第一个痛点就是安全合规。公司内网系统里的接口返回数据，往往带着真实用户信息、内部订单号、业务敏感字段。你把这段JSON复制到第三方网站上，数据就经过了别人的服务器，这在绝大多数公司的安全审计里都是过不了的。越是正规团队，对"数据出内网"管得越严，我在第一家公司就被运维提醒过，浏览器访问外网格式化网站会被网关记录。第二个痛点是效率。在线工具从打开浏览器、找到书签、等待页面加载、粘贴、点击格式化，到格式化完成，一套流程下来快则十秒，慢则半分钟。一天排查十几个接口，光这个动作就要吃掉十几分钟。而本地工具是常驻的，粘贴、格式化、复制，三秒钟内完成。第三个痛点是定制能力。在线工具功能是死的，你没法按自己的使用习惯加"键名排序""压缩对比""行号定位"这些功能。自己做的工具，想加什么加什么。

1.2 工具的边界：该做哪些，不该做哪些

动手之前先想清楚范围。很多人的第一个版本容易失控，一上来就想做成一站式JSON工作台，结果做了三个月还在改bug。我的建议是首版只做四件事：格式化、压缩、语法高亮、错误定位。这四件事能覆盖90%的日常需求。

不做哪些？不做JSON树形折叠编辑——那是复杂得多的工作，牵扯到响应式重建、节点操作、撤销重做，工作量直接翻几倍。不做JSON和XML互转、不做JSONPath查询，这些是独立的垂直功能，后续可以在稳定版基础上慢慢加。首版把格式化主链路做稳，比什么都强。另外我建议把工具做成一个独立的Vue3组件，放在src/components/JsonFormatter/目录下，这样以后不管是扔进管理系统的某个页面、还是单独挂一个/tools/json路由，都很方便。

2. 格式化引擎与组件分离：先把核心逻辑从页面里抽出来

2.1 纯函数引擎的代码结构

很多人的第一版是直接在Vue组件里写一个handleFormat方法，里面十行代码把JSON.parse和JSON.stringify串起来，看起来没问题，但一旦加上错误定位、键名排序、压缩模式这些需求，组件会迅速膨胀成几百行的大杂烩。

正确的做法是把格式化逻辑抽成一个纯函数模块，组件只负责"拿到输入"和"展示结果"。这里说的纯函数，指的是不依赖Vue的任何API、只做输入输出转换的函数。这样做的收益有三个：可以单独写单元测试，可以在Web Worker里复用，以后换到React或者做成CLI工具也能直接搬。

引擎模块我放在src/utils/jsonFormatter.ts，核心代码如下。

// src/utils/jsonFormatter.ts export interface JsonFormatResult { ok: boolean text: string errorMsg: string errorLine: number errorColumn: number errorPosition: number } export function formatJson( input: string, indent: number | string = 2, options: { sortKeys?: boolean } = {} ): JsonFormatResult { try { let value = JSON.parse(input) if (options.sortKeys) { value = deepSort(value) } return { ok: true, text: JSON.stringify(value, null, indent), errorMsg: '', errorLine: 0, errorColumn: 0, errorPosition: -1 } } catch (err) { const error = err as SyntaxError const position = extractErrorPosition(error.message) const { line, column } = lineColumnAtPosition(input, position) return { ok: false, text: '', errorMsg: error.message, errorLine: line, errorColumn: column, errorPosition: position } } } export function compressJson(input: string): JsonFormatResult { try { JSON.parse(input) return { ok: true, text: JSON.stringify(JSON.parse(input)), errorMsg: '', errorLine: 0, errorColumn: 0, errorPosition: -1 } } catch (err) { const error = err as SyntaxError const position = extractErrorPosition(error.message) const { line, column } = lineColumnAtPosition(input, position) return { ok: false, text: '', errorMsg: error.message, errorLine: line, errorColumn: column, errorPosition: position } } }

这里有个细节值得说明：JSON.stringify(value, null, indent)的第三个参数indent，除了传数字（表示几个空格），还能直接传字符串。比如传'\t'就可以输出Tab缩进。所以组件里的"缩进方式"下拉框，传入数字或Tab字符都行，引擎不用做特殊处理。

extractErrorPosition和lineColumnAtPosition这两个辅助函数，作用是把浏览器报错信息里的"position 42"这种下标转成我们人能看懂的第几行第几列，这个后面讲错误处理的时候详细展开。

另一个容易出坑的地方是deepSort。键名排序不是简单地对最外层做Object.keys(obj).sort()，必须递归处理嵌套对象和数组。我见过有人忽略了数组内的对象字段，结果外层排好了，内层还是乱序，调试半天。

function deepSort(value: unknown): unknown { if (Array.isArray(value)) { return value.map((item) => deepSort(item)) } if (value !== null && typeof value === 'object') { const sorted: Record<string, unknown> = {} const keys = Object.keys(value as Record<string, unknown>).sort() for (const key of keys) { sorted[key] = deepSort((value as Record<string, unknown>)[key]) } return sorted } return value }

2.2 组件层用Composition API接住引擎

组件层的代码同样要克制。我的做法是组件里只维护四类状态：输入文本、输出文本、错误信息、若干配置项。所有派生状态用computed，所有异步行为用watch加定时器管理。

<script setup lang="ts"> import { ref, computed, watch, onUnmounted } from 'vue' import { formatJson, compressJson } from '@/utils/jsonFormatter' import { highlightJson } from '@/utils/jsonHighlighter' const inputText = ref('') const outputText = ref('') const errorMessage = ref('') const sortKeys = ref(false) const indentMode = ref<'two' | 'four' | 'tab'>('two') const highlightedResult = computed(() => { if (!outputText.value) return '' return highlightJson(outputText.value) }) function resolveIndent(): number | string { if (indentMode.value === 'tab') return '\t' return indentMode.value === 'two' ? 2 : 4 } function runFormatter(mode: 'format' | 'compress' = 'format'): void { if (!inputText.value.trim()) { outputText.value = '' errorMessage.value = '' return } const result = mode === 'format' ? formatJson(inputText.value, resolveIndent(), { sortKeys: sortKeys.value }) : compressJson(inputText.value) if (result.ok) { outputText.value = result.text errorMessage.value = '' } else { outputText.value = '' errorMessage.value = `第 ${result.errorLine} 行，第 ${result.errorColumn} 列：${result.errorMsg}` } } </script>

用过Vue2的老开发应该能感觉到，同样的逻辑如果用Options API写，data、methods、computed、watch四个区域来回切，而且watch里要访问this，类型推导也费劲。Composition API最大的好处是让"围绕一个能力的代码"天然聚在一起，格式化相关的状态和逻辑写在同一个函数作用域里，这个工具的代码边界一下就清晰了。

2.3 为什么不在computed里做防抖

有个问题我见过不少人踩：想要"边输入边格式化"的效果，于是在computed里写formatJson(inputText.value)，然后外面套防抖。这是行不通的，因为computed是同步求值的，它没办法被延迟。你在computed的getter里setTimeout，返回的永远是上一次的值，完全失去了响应式意义。

正确的姿势是watch加定时器：

let formatTimer: ReturnType<typeof setTimeout> | null = null watch(inputText, () => { if (formatTimer) clearTimeout(formatTimer) formatTimer = setTimeout(() => { runFormatter('format') }, 400) }) onUnmounted(() => { if (formatTimer) clearTimeout(formatTimer) })

watch是对"变化"这个动作做响应，它天然适合接防抖：用户停了下来，才触发真正的格式化。防抖间隔我实测400毫秒比较合适，低于200毫秒会出现输入过程明显的闪跳，高于800毫秒又会觉得"卡卡的"。当然这个值也取决于格式化引擎的耗时，如果接入了大JSON场景的Worker方案，防抖间隔可以放宽到300毫秒甚至更短，因为格式化本身已经不占用主线程了。

3. 格式化与语法高亮：从JSON.parse到带颜色的输出

3.1 JSON.parse校验加stringify格式化，够用吗

先回答一个很多人问过的问题：格式化算法要不要自己手写解析器？答案是首版完全不需要。JSON.parse本身就是一个经过万级测试的严格解析器，用它做校验，再用JSON.stringify(value, null, indent)做格式化输出，这是最稳妥的组合。自己手写解析器，要去处理字符串转义、Unicode代理对、数字边界，工作量巨大且极易出bug，除非你的需求是支持JSON5、注释、尾逗号这类非标准语法，否则别碰。

JSON.stringify的space参数之前的null位置也很讲究。如果写成JSON.stringify(value)，得到的是压缩后的单行文本。这个行为被我们用来实现"压缩"功能：先parse校验，再stringify无缩进输出。所以压缩和格式化在引擎里只是space参数不一样，其余逻辑完全复用。

3.2 tokenize：把格式化文本切成有语义的碎片

格式化只是把JSON变得有缩进和换行，真正让工具好用的是语法高亮。高亮的难点在于：不能简单地把整个输出文本包一层颜色，而要把文本拆成"键名""字符串""数字""布尔值""null""标点""空白"这些有语义的token，再分别上色。

我推荐的正则tokenize方案是这样的。先把格式化后的文本按语义切分，核心是两条正则的顺序不能反：键名正则/"([^"\\]|\\.)*"(?=\s*:)/一定要放到字符串正则前面，因为键名本质上也是字符串，只有靠后面的(?=\s*:)前瞻判断"这个引号后面跟的是冒号"才能区分它是键名还是字符串值。顺序一旦搞反，所有键名会被当成字符串高亮，整个JSON的颜色就全乱套了。

// src/utils/jsonHighlighter.ts export type TokenType = 'key' | 'string' | 'number' | 'boolean' | 'null' | 'punct' | 'space' export interface Token { type: TokenType value: string } export function tokenizeJson(text: string): Token[] { const tokens: Token[] = [] const rules: { type: TokenType; pattern: RegExp }[] = [ { type: 'key', pattern: /"([^"\\]|\\.)*"(?=\s*:)/y }, { type: 'string', pattern: /"([^"\\]|\\.)*"/y }, { type: 'number', pattern: /-?\d+(?:\.\d+)?(?:[eE][+-]?\d+)?/y }, { type: 'boolean', pattern: /true|false/y }, { type: 'null', pattern: /null/y }, { type: 'punct', pattern: /[{}[\],:]/y }, { type: 'space', pattern: /\s+/y } ] let pos = 0 while (pos < text.length) { let matched = false for (const { type, pattern } of rules) { pattern.lastIndex = pos const match = pattern.exec(text) if (match && match.index === pos) { tokens.push({ type, value: match[0] }) pos += match[0].length matched = true break } } if (!matched) { tokens.push({ type: 'string', value: text[pos] }) pos += 1 } } return tokens }

这段代码用了正则的sticky标志y，它和g标志的区别是：g允许从lastIndex往后任意位置查找，而y强制从lastIndex精确位置匹配。在这种"必须逐字符顺序扫描"的场景里，y标志写起来要干净得多，不需要每次判断match.index === pos之外再处理跳过的情况。现代浏览器和Node.js对y标志的支持已经很完善，可以放心用。

生成高亮HTML的时候，还有一个必须处理的点：把所有原始文本做HTML转义。JSON里的字符串值完全可能是<script>、<img onerror="...">这种内容，如果不过转义直接拼进v-html，就是妥妥的XSS注入点。

function escapeHtml(str: string): string { return str .replace(/&/g, '&amp;') .replace(/</g, '&lt;') .replace(/>/g, '&gt;') .replace(/"/g, '&quot;') .replace(/'/g, '&#39;') } export function highlightJson(text: string): string { return tokenizeJson(text) .map((token) => { const typeClass: Record<TokenType, string> = { key: 'json-key', string: 'json-string', number: 'json-number', boolean: 'json-boolean', null: 'json-null', punct: 'json-punct', space: '' } const cls = typeClass[token.type] if (!cls) return escapeHtml(token.value) return `<span class="${cls}">${escapeHtml(token.value)}</span>` }) .join('') }

3.3 v-html渲染的XSS坑

上面这段代码把转义放在了最内层，这个顺序非常重要。正确的思路是：我们动态拼接的<span>标签是可信的，标签内部包裹的内容必须全部经过escapeHtml。也就是说，先转义用户内容，再包上我们自己的标签，顺序不能变。

有人图省事，直接对整段JSON文本先做一次JSON.stringify再替换，这样确实能去掉危险字符，但连引号引号都变成\"了，展示出来完全不是JSON的样子。还有人用DOMPurify做一遍消毒，这当然也能用，但性能开销不值当——我们自己就是产出方，把好转义这一道关就够了。

样式方面，我用的配色方案是经典的明亮主题：键名蓝色、字符串绿色、数字橙色、布尔值和null用紫色、标点灰色。如果你做的工具要支持暗色模式，建议用CSS变量而不是硬编码颜色，切换主题时只需要改一组变量。

4. 错误输入的体验：从浏览器堆栈到人话提示

4.1 常见非法JSON形态清单

格式化工具最难的一环其实不是格式化本身，而是告诉用户"你为什么错了"。同样的错误，浏览器返回的Unexpected token '}' in JSON at position 42，一般用户根本看不懂position 42在哪。

我整理了日常使用中最高频的几类非法JSON，每类都有对应的提示场景。

这些形态的错误提示如果只是原样抛出浏览器信息，用户根本不知道该怎么改。所以错误处理这块的核心工作，就是把position转成行列号，再给出针对性的提示文案。

4.2 行列号计算的细节

从浏览器报错信息里提取position，再用position反推行列号，这个逻辑很直接，但有一个性能细节要提一下。

function extractErrorPosition(message: string): number { // 统一处理各浏览器的报错格式 const match = message.match(/position\s+(\d+)/i) if (match) return parseInt(match[1], 10) return -1 } function lineColumnAtPosition(text: string, position: number): { line: number; column: number } { if (position < 0) { return { line: 1, column: 1 } } let line = 1 let column = 1 for (let i = 0; i < position && i < text.length; i++) { if (text[i] === '\n') { line += 1 column = 1 } else { column += 1 } } return { line, column } }

这里我故意没用text.slice(0, position).split('\n')的写法，因为slice会拷贝一次字符串、split还会生成一个数组，对于一两千行的JSON来说浪费内存。直接遍历到position的位置，时间和内存都省。虽然单次看不出来，但配合防抖后的高频调用，积少成多。

提取position的正则也要兼容不同浏览器。Chrome的格式是in JSON at position 42，Firefox是at line 1 column 5，Safari则直接没有位置信息只给描述文字。所以extractErrorPosition匹配不到时返回-1，lineColumnAtPosition拿到-1就返回第一行第一列，同时把原来的原始错误信息保留在errorMsg里作为兜底。

4.3 实时格式化与防抖策略

有了可靠的错误定位，实时格式化才有意义。用户粘贴完JSON的瞬间就能看到红色错误提示，比自己手动点"格式化"按钮再等结果要高效得多。

但这里有个体验细节：并不是所有输入阶段都适合实时格式化。用户在粘贴多行JSON的过程中，会有无数个瞬间处于"非法状态"——粘贴到一半、括号还没闭合，都会触发错误提示。如果每敲一个字符就格式化一次，提示会疯狂闪跳，非常烦躁。

所以我的实现里分了两条路：

• 用户手动点击"格式化"按钮：立即执行，无视防抖。
• 输入变化触发的自动格式化：400毫秒防抖，且只在输入文本非空时执行。

这样既保证了主动操作的即时性，又避免了被动触发时的抖动。watch里清掉上一个定时器的写法前面讲过，注意组件卸载时也要清理，否则定时器会继续触发已经卸载的组件状态更新。

5. 大JSON卡顿优化：从防抖到Web Worker

5.1 先定位卡顿点

做性能优化之前，先说清楚JSON格式化工具卡顿到底卡在哪。很多人第一反应是"格式化太慢"，但实测下来，一两兆的JSON文本，JSON.parse加JSON.stringify的耗时通常也就是几十到一两百毫秒，没那么夸张。真正卡的是后面的渲染：高亮tokenize加生成大量HTML字符串，再让浏览器重绘一个巨大的<pre>节点，这个阶段才是大户。

所以优化的优先级是：先看渲染，再看解析。

我的经验阈值是这样：100KB以内的JSON，怎么写都不会卡，直接走同步逻辑就好；100KB到500KB之间，高亮渲染开始变慢，需要做"限流"和"渲染节流"；超过500KB，解析本身开始走高，就要考虑Web Worker了。这里的数值不是拍脑袋，是我用一段10万行、约1.5MB的真实配置JSON测出来的。

5.2 Worker方案落地

Web Worker的核心价值，是把JSON.parse和JSON.stringify这些CPU密集操作从主线程挪出去。注意我这里说的是"解析和格式化"，不包括高亮和渲染——因为Worker只能返回字符串，生成HTML字符串的部分如果也扔进去，返回值会很大，postMessage传递的成本反而可能高于直接在主线程做。实测下来，高亮部分的耗时占比并不高，留在主线程完全可以接受。

用Vite创建项目的话，Worker的使用有个非常方便的语法：?worker后缀。在Vite 5以上的版本里，直接import JsonFormatWorker from '@/workers/jsonFormat.worker?worker'，开发环境它会自动打包，生产环境也会按Worker单独产出资源。

// src/workers/jsonFormat.worker.ts import { formatJson } from '@/utils/jsonFormatter' self.onmessage = (e: MessageEvent) => { const { input, indent, sortKeys } = e.data const result = formatJson(input, indent, { sortKeys }) self.postMessage(result) }

组件侧接Worker时有一个特别容易踩的坑：连续多次触发格式化时，上一次Worker的返回结果可能晚于下一次的结果，导致旧结果覆盖新结果。解决方法是用一个自增序列号，每次发出新任务时seq++，Worker返回时校验序列号是否还是最新，不是就丢弃。

let formatWorker: Worker | null = null let workerSeq = 0 function formatInWorker(input: string): void { if (!formatWorker) { formatWorker = new JsonFormatWorker() } const seq = ++workerSeq formatWorker.onmessage = (e: MessageEvent) => { if (seq !== workerSeq) return const result = e.data as JsonFormatResult applyResult(result) } formatWorker.postMessage({ input, indent: resolveIndent(), sortKeys: sortKeys.value }) }

这个"过期响应丢弃"的套路，不只是Worker适用，将来你接流式接口、做搜索联想下拉，凡是"请求A晚于请求B发出但先于其返回"的场景，都用得上。

5.3 渲染侧兜底：截断与折叠

Worker解决了解析，但渲染侧还得有兜底方案。我的做法是给高亮输出加上"超长截断"策略：当输出文本的行数超过5000行时，只渲染前5000行，后面用一个提示条提示"内容过长，已截断显示，格式化结果不受影响"。为什么是5000行？因为实测一个<pre>节点挂大约5000行带内联标签的HTML，Chrome和Edge的渲染还能保持在流畅范围，再往上就会出现明显的滚动卡顿。

截断的逻辑要放在tokenize之后的渲染阶段，不要只截前半部分字符串——那会把最后一个token切断，导致颜色错乱。正确做法是tokenize完，按token的行信息累计，超过阈值就停止组装HTML。另外，v-html渲染出来的<pre>如果还要做"点击高亮某一行"之类的交互，裁剪后行号会错位，我的建议是截断模式下不做行级交互，只保证能看。

6. 集成进真实项目的几个实战细节

6.1 组件还是独立路由页面

很多人在"做成组件还是做成页面"上犹豫。我的建议很直接：先做成组件，再花五分钟包一层页面导出路由。组件保证了复用性，页面保证了可达性。在Vue3里，用一个简单的defineAsyncComponent按需加载这个页面组件，还能避免把它打进主包影响首屏。

// router/index.ts const JsonTool = () => import('@/pages/JsonTool.vue') const routes = [ { path: '/tools/json', name: 'JsonTool', component: JsonTool } ]

调试类工具天然适合异步路由，因为用户的访问频率低，完全可以等需要时再拉取。开发环境用Vite时，这个文件的编译也不影响主项目的热更新速度。

6.2 复制和下载功能的完整实现

格式化完成之后，"复制结果"比"下载文件"用得多，而且多到不是同一数量级。复制要做的兼容处理主要是老版浏览器不支持navigator.clipboard，得回退到document.execCommand('copy')方案。

async function copyText(text: string): Promise<boolean> { if (navigator.clipboard && window.isSecureContext) { try { await navigator.clipboard.writeText(text) return true } catch { return legacyCopy(text) } } return legacyCopy(text) } function legacyCopy(text: string): boolean { const textarea = document.createElement('textarea') textarea.value = text textarea.style.position = 'fixed' textarea.style.opacity = '0' document.body.appendChild(textarea) textarea.select() const ok = document.execCommand('copy') document.body.removeChild(textarea) return ok }

这里有个特别隐蔽的坑：在非本地环境（非localhost）下，navigator.clipboard即使存在也可能因为权限策略返回undefined，所以判断条件必须是navigator.clipboard && window.isSecureContext，只判断前者是不够的。

下载文件就简单很多，Blob加URL.createObjectURL就行，唯一要注意的是用完后revokeObjectURL释放资源，否则频繁下载会把浏览器的对象URL池占满。

function downloadJson(text: string, filename = 'formatted.json'): void { const blob = new Blob([text], { type: 'application/json;charset=utf-8' }) const url = URL.createObjectURL(blob) const a = document.createElement('a') a.href = url a.download = filename a.click() URL.revokeObjectURL(url) }

6.3 键名排序与大小写细节

排序功能做之前，我一直觉得它是鸡肋，直到有次对比两个不同团队返回的JSON结构，一个用字段顺序排列、一个乱序输出，肉眼对比差点看瞎。加了sortKeys排序后，两段JSON一格式化、一排序，结构差异一目了然。所以排序功能强烈建议首版就做进去，它几乎零成本，收益却不小。

还有一个跨端协作的场景值得注意。Java后端同事的Bean字段命名、Python后端返回的snake_case字段、前端自己拼的camelCase字段，在同一个项目里混着出现太常见了。有次一个Java同事问我，他Bean里首字母大写的字段，接口返回的JSON里怎么变小写了——这是Jackson默认命名策略导致的序列化行为。当时的场景里，他拿到的是格式化后的JSON，一眼就看出键名和他想的对不上。这种"键名大小写形态"的问题虽然不是格式化工具能解决的，但工具能通过清晰的键名高亮和排序，帮你在第一时间发现它，这就是个很实用的价值。

6.4 后续还能扩展的方向

工具上线用了一个月后，我收到了不少真实需求，按优先级排序，值得做的扩展方向大致是这些。

第一是JSON压缩率统计。在压缩按钮旁边显示原文本大小、压缩后大小、压缩率，这个功能做起来十分钟，但对运营同学来说很有价值，他们经常要贴长JSON到配置系统里，对长度有硬性限制。第二是结构对比功能。输入两段JSON，输出字段差异明细，这个功能做起来比想象中复杂，需要先转成树形再diff，建议放二期。第三是JSONPath测试，输入$.data.items[*].id这样的路径，实时标出匹配结果，这个对接口联调帮助很大。三个方向里，我最推荐先做压缩率统计，因为代码量小、感知度高、几乎没有风险。

我在实际落地中还有几个小提醒。一是组件尽量使用scoped样式，高亮用的CSS变量建议定义在:root或主题配置里，避免子组件样式互相污染。二是如果项目用了TypeScript，给JsonFormatResult定义好完整的接口类型，后面扩展字段时编译器能帮你兜底，比到处写any省心得多。三是这个工具刚开始只在本地开发环境跑，后来因为后端同学也总过来借，我才把它挂到内网的静态资源服务上，结果收到一批建议——所以做的时候务必当成一个长期维护的组件来设计，别想着临时用用，不然后面改起来全是债。