做前端这么多年，我越来越觉得一个项目能不能长久稳定地维护下去，很多时候不取决于用了多新的框架、多炫的动画，而是取决于最基础的那一层HTML标签写得够不够“固定”。这里说的“固定”，不是指把标签写死、不让人改，而是指一套结构清晰、语义准确、职责分明的标签骨架。骨架稳了，样式、脚本、数据渲染才有地方安放，框架本身也才能真正立得住。
这个道理听起来简单，但我在实际评审代码时见过太多反面案例：有的页面div套div套了七八层，找半天找不到内容节点；有的img标签该写的宽高不写，页面加载时上下乱跳；还有的input标签明明有更合适的type不用，非要手写正则去校验。这些问题的根源，都是最开始那批“固定标签”没有搭好。这篇博文我就从HTML固定标签这个角度出发，把“为什么固定标签能让框架更稳固”这件事讲透，同时拆解几个高频标签的实操细节，再结合Vue这类现代框架和HTML邮件的场景，聊聊怎么把基础标签的功力真正转化为项目的稳定性。
如果你正在写HTML页面、维护老项目，或者打算用Vue、React这类框架做新项目但心里没底，这篇文章应该能帮你把地基重新夯实一遍。
1. 重新认识“固定HTML标签”这个概念
1.1 固定标签是页面的承重墙
很多人把HTML标签当成“给内容加个样式的外壳”，这是最危险的误解。我习惯把HTML标签比作建筑的承重墙：doctype是地基的等级声明，html标签是整个建筑的外轮廓，head区是设计图纸和设备间，body区才是住户实际生活的空间。承重墙不能随便拆，标签的层级和位置也不能随便挪。
“固定”这个字眼，拆开来看有两层意思。
第一层是文档结构固定。一个标准HTML文档必须按照<!doctype html>→<html>→<head>+<body>的顺序组织，head里必须有字符集声明，body里的块级内容和内联内容要有基本秩序。这个结构是所有浏览器、爬虫、屏幕阅读器共同遵守的默认协议，谁破坏了它，谁就要承担跨浏览器兼容的后果。
第二层是标签职责固定。每个标签都有它本来的语义身份：header就是页眉，nav就是导航，article就是文章主体，button就是按钮，a就是链接。你要是非用div去模拟按钮，用span去假装标题，短期看样式没差别，长期看维护的人得靠猜才能读懂你的意图，自动化测试和SEO也会跟着遭殃。
所以这篇文章里说的“框架更稳固”，指的是结构性稳固和语义性稳固两层叠加。前者让页面在不同浏览器和设备上表现一致，后者让团队协作和程序解析变得可靠。这两层打好了，上层不管是Vue、React还是什么新框架，都只是在固定的地基上做装修而已。
1.2 逐步拆解：一份标准HTML骨架的逐行含义
先看一段最标准、最“固定”的HTML骨架，凡是新建页面我都会先用它打底：
<!doctype html> <html lang="zh-cn"> <head> <meta charset="utf-8"> <meta name="viewport" content="width=device-width, initial-scale=1"> <title>页面标题</title> </head> <body> <!-- 页面内容 --> </body> </html>逐行说，别小看这几行，每一行都有它存在的理由。
<!doctype html>是给浏览器的“文档模式”指令。它告诉浏览器：请用最新的标准模式来渲染这个页面。如果没有这行声明，浏览器会进入诡异模式（Quirks Mode），盒模型计算方式、行高、字体渲染都会回到IE5时代的老规则，同一个页面在Chrome和Edge里可能差出几十个像素。我遇到过一个老项目，页面顶部漏了doctype，结果所有百分比宽度在Safari里都偏大，排查了大半天，最后加上doctype瞬间全好了。
<html lang="zh-cn">声明页面语言。这个标签平时看不见摸不着，但对SEO和屏幕阅读器极其重要。搜索引擎会根据lang属性判断页面内容该收录进哪个语言索引，屏幕阅读器也会根据它选择合适的语音包朗读。中文站点建议统一写lang="zh-cn"，顺手给html标签加上这个属性，成本几乎为零，收益却很大。
<head>区里的<meta charset="utf-8">是防乱码的关键。它告诉浏览器用UTF-8字符集解码文件字节。如果你的HTML文件保存格式是UTF-8，但页面里没声明charset，浏览器可能按系统默认编码去猜，中文内容就会变成“���”一类的乱码。这个meta标签必须放在head最前面，因为浏览器一旦遇到它就会重新按指定编码解析，放得越靠前，解析出错的可能性越小。
<meta name="viewport">是移动端适配的开关，width=device-width表示页面宽度跟随设备宽度，initial-scale=1表示初始缩放比例为1:1。没有这个标签，手机浏览器会默认按980像素宽度渲染页面再缩小，文字会变得很小，用户需要手动放大才能看清。
<title>是页面唯一一个既影响SEO标题、又影响浏览器标签页显示、还影响分享卡片标题的标签。注意它只能写在head里，不能在body里重复出现。
说句题外话，很多教程会强调“HTML很简单”，但从这几行骨架就能看出，简单的标签背后牵涉的是浏览器机制、字符编码、SEO策略、无障碍访问等多个专业领域。把这些固定标签理解到位了，后面的路才好走。
2. 高频常用标签的语义选择与实操细节
2.1 input标签：别只会用type="text"
如果做个统计，“input标签被滥用排行榜”第一名一定是type="text"。明明有更合适的类型不用，全靠JS手写校验，这是典型的把框架当傻子。现代浏览器的input已经内置了一批非常实用的类型，每个类型都对应固定的行为逻辑和移动端键盘模式。
我常用的几个类型：
type="email"：PC端提交时会自动校验邮箱格式，移动端会弹出带@的键盘。虽然它的内置校验不算严格，但这层基础过滤足以挡掉一大半用户手滑输入的错误。type="tel"：移动端弹数字键盘，适合手机号输入。注意它不会自动校验位数，位数校验还是得靠JS。type="number"：只能输数字，带增减按钮。但它有个坑：在部分浏览器里可以输入字母“e”，因为e在科学计数法里是合法字符，真要限制纯整数，建议配合inputmode="numeric"一起用。type="password"：输入内容打码显示，浏览器还自带“显示密码”按钮。type="hidden"：页面不可见但随表单提交，用来传用户ID、token这类“只传递不展示”的数据。type="checkbox"和type="radio"：前者多选，后者单选。想要让它们更易点中，最优做法是用<label>包住input和文字，让文字也变成点击区域。
一个非常典型的错误写法是把手机号、邮箱全写成type="text"然后加一堆正则。我自己的经验是：HTML层能做的校验交给HTML，JS层只做HTML管不了的业务校验，比如“两次输入的密码必须一致”“结束日期不能早于开始日期”。这种分工方式既少写代码，又天然适配无障碍访问。
另外补充一个细节：所有input标签，只要参与了表单提交，就要有name属性。没有name的input，无论填了什么都不会被提交到后端。这个属性我每次都会检查，它才是表单数据真正的“变量名”。
2.2 img标签：渲染稳定性的隐藏关键点
图片加载是页面布局“抖动”的高发区。你打开一个文章页，文字先显示，图片加载完成后把内容往下顶，滚动条瞬间变短——这种体验就是典型的没写固定宽高导致的。img标签的稳定性核心就三个点：宽高、alt、loading。
宽高方面，现在HTML允许这样写：
<img src="photo.jpg" alt="项目现场照片" width="800" height="600">浏览器会用CSS单位换算显示尺寸，但真正的作用是提前预留图片空间，让图片加载前后页面高度保持不变。如果你不确定图片原始尺寸，可以用aspect-ratio配合width: 100%来固定比例：
<img src="cover.jpg" alt="封面图" style="width: 100%; aspect-ratio: 16 / 9; object-fit: cover;">这样在图片还没加载出来的时候，容器就已经占住了16:9的横向条，加载完成后不会顶动下面的内容。
alt属性是图片的可访问替代文本，也是SEO的重要字段。纯装饰性图片建议写alt=""空值，让屏幕阅读器跳过；内容型图片必须写能描述图片内容的文字，不要写“图片”“123”这种废词。
loading属性是性能优化的小开关。首屏以上的图片不写loading，让浏览器默认立即加载；首屏以下的图片写loading="lazy"，让浏览器滚动到附近时才加载。一条规则：首屏图不用管，首屏外全部lazy。
再提一个热词里的场景，img+标签+点击跳出图层，这在电商和作品集网站里特别常见——点击小图，弹出大图预览层。实现方式有很多，最稳的是用一个隐藏的全屏遮罩层，点击图片时给遮罩层加display: flex，同时把大图src赋给遮罩层里的img。具体代码我放到第4章实操部分再展开。
2.3 表格系列标签：别让数据乱成一锅粥
表格类标签的热度一直很高，尤其是colspan标签是什么、怎么用。colspan的中文含义是“列跨度”，它用来让一个单元格横向合并占据多列。比如做一个课程表，表头“周一”和“周二”各自跨1列，但表头“午休”要跨4列，就得写colspan="4"。
rowspan则是“行跨度”，让单元格纵向合并占据多行。这两个属性用好了，表格能表达非常复杂的二维关系，用不好就会行列错位。我的实操建议是：合并单元格时先画草稿，把每行每列的网格数标出来，再写HTML，能减少大量返工。
另外要说一个老生常谈但很多人不做的：表格一定要用<table>语义标签，而不是用一堆div拼网格。表格类数据（Excel导出的数据、账目明细、排班表）天然是二维结构，屏幕阅读器可以按行列朗读，搜索引擎也能更好理解内容。里面用<thead>包表头，<tbody>包表体，<th>表示表头单元格（默认加粗居中），<td>表示普通单元格。这套固定结构虽然写起来啰嗦，但它就是表格的“固定框架”，换了任何框架都不敢轻视它。
在现代前端里，纯表格展示数据还好，如果要做“金额列右对齐、状态列着着色、点击行跳转”这类交互，我建议还是交给组件库的table组件，但底层数据结构依然是每行每列的二维关系。理解原生表格的colspan和rowspan，再去看组件库的列合并、行合并配置，几乎是无缝切换。
3. 固定标签与现代框架：稳定的骨架，自由的交互
3.1 框架渲染的底层依然是HTML标签
Vue、React这类现代框架，给人的感觉是“一切皆组件、数据驱动视图”，好像HTML已经不重要了。但真相是：框架的运行时再怎么抽象，最终交付给浏览器的依然是标准的HTML标签。你可以写const el = document.createElement('div')，它是div；你写JSX<div className="card">，它最终渲染出来还是div。框架只是帮你管理这些标签的创建、更新和销毁，并没有创造新标签。
理解了这一点，你就明白“固定HTML标签”在框架项目里意味着什么。如果基础标签选错了，框架把它渲染出来就是个错的结构：用了非语义标签导致SEO不识别，输入框类型选错导致移动端键盘不对，图片没写尺寸导致组件加载时页面抖动——这些问题不会因为用了Vue而自动消失，反而因为框架的响应式更新机制，可能被放大成更复杂的连锁问题。
我有一次接手一个Vue项目，列表页每个卡片都用div堆砌，标题用div class="title"，内容用div class="desc"。表面看没什么问题，但客户提出要求“首页文章标题要在搜索结果里高亮展示”，这时候才发现全文没有一个真正的<h2>标题标签，搜索引擎根本不知道哪段文字是标题。最后只能全局替换标签，费时费力。如果最开始就坚持语义标签，这个需求只要加两行样式就能完成。
3.2 实操案例：修改Vue3中Tabs标签页的样式
Tabs标签页是后台管理系统里最常见的组件。在Vue3项目里用Element Plus这类组件库，Tabs的原生结构默认长这样：
<div class="el-tabs"> <div class="el-tabs__header"> <div class="el-tabs__nav-wrap"> <div class="el-tabs__nav"> <div class="el-tabs__item">选项一</div> <div class="el-tabs__item">选项二</div> </div> </div> </div> <div class="el-tabs__content"> <!-- 面板内容 --> </div> </div>组件库的标签样式由内部类名控制，直接改scoped样式往往不生效，因为scoped会给当前组件的DOM元素添加>.el-tabs :deep(.el-tabs__item) { font-size: 14px; color: #666; } .el-tabs :deep(.el-tabs__item.is-active) { color: #ff4d4f; font-weight: 600; } .el-tabs :deep(.el-tabs__active-bar) { background-color: #ff4d4f; height: 3px; }
这是固定HTML标签思维在框架里的一次实战：组件库已经替你呈现了最稳定的标签结构，你需要做的是理解这些结构，用深度选择器精准定位，而不是写一堆!important去强行覆盖。我见过太多人一改组件样式就!important大法，结果全局污染，换个页面组件也跟着变样。正确做法是先审查组件实际的渲染结构，再针对特定类名做覆盖，范围越小越稳。
3.3 语义化固定标签对SEO与可访问性的一本万利
语义化标签是“固定标签”里的最高阶体现。很多人觉得SEO是运营的事、可访问性是公益的事，跟开发无关，但在固定标签的视角下，这两件事都是开发分内的事。
从SEO角度看，搜索引擎爬虫解析页面时，会重点读取h1~h6标题层级、a链接文本、img的alt、article包裹的内容区域。一个标准的内容页应该只有一个h1，下面用h2分章节，h3做更低级的小标题。这种层级清晰的页面，爬虫很容易判断重点，排名加权自然更友好。
从可访问性角度看，屏幕阅读器用户通过键盘和读屏软件浏览页面，他们依赖标签语义来理解结构。nav区域可以快速跳转，button可以用回车键触发，table可以朗读单元格内容。如果你的页面全是div和span，读屏软件读出来的就是一大坨没有任何结构感的文字，用户体验极差。
我做项目前会先花10分钟列一个“标签地图”：页眉用header，主导航用nav，中间内容按模块用section搭配h2标题，独立文章用article，侧栏用aside，页脚用footer。这套地图一旦定下来，后续开发的所有人都会按这个“固定框架”来填内容，页面风格的统一性会非常高。
4. 基于固定标签的常见扩展场景实操
4.1 把HTML安全转换为Markdown的通用思路
“html转为md”是个高频需求，做文档系统、爬虫内容处理、博客迁移时都会碰到。转换的核心思路很简单：遍历HTML的DOM树，根据标签类型映射到对应的Markdown语法。
常用映射关系是这样一张表：
| HTML标签 | Markdown语法 | 说明 |
|---|---|---|
h1~h6 | #~###### | 标题层级一一对应 |
p | 直接输出文本 + 换行 | 段落 |
a | [文本](链接) | 链接 |
img |  | 图片 |
strong/b | **文本** | 加粗 |
em/i | *文本* | 斜体 |
ul+li | - 项目 | 无序列表 |
ol+li | 1. 项目 | 有序列表 |
blockquote | > 引用 | 引用 |
code | `代码` | 行内代码 |
pre | 代码块缩进或围栏 | 块级代码 |
写转换脚本时，我不建议用正则去匹配HTML，因为HTML的嵌套结构复杂，正则很容易被边界情况击穿。我更推荐用现成的解析器，比如Node.js环境用html-to-markdown，Python环境用html2text，先用DOM解析器把HTML变成节点树，再按标签类型递归转换。
一个常见的坑是嵌套列表。Markdown的无序列表里再嵌套一个无序列表，需要缩进两个空格，很多转换器默认不做这个缩进，导致渲染后嵌套层级丢失。处理时可以在递归函数里传入当前列表层级，根据层级生成对应数量的缩进。
4.2 用PyQt5显示HTML内容的实现要点
“pyqt5显示html”这个需求，一般出现在桌面工具里需要渲染富文本、图表或复杂排版的时候。PyQt5里的QTextBrowser或QTextEdit可以直接通过setHtml()方法渲染HTML字符串。
基本写法：
from PyQt5.QtWidgets import QApplication, QTextBrowser import sys app = QApplication(sys.argv) browser = QTextBrowser() html_content = """ <!doctype html> <html lang="zh-cn"> <head><meta charset="utf-8"></head> <body> <h1>项目报告</h1> <p>这是一个<strong>测试</strong>页面。</p> <ul> <li>条目一</li> <li>条目二</li> </ul> </body> </html> """ browser.setHtml(html_content) browser.show() sys.exit(app.exec_())但要注意，PyQt5的富文本引擎基于Qt自己的HTML子集，不是完整浏览器渲染引擎。它支持的标签主要包括p、h1~h6、strong、em、ul、ol、a、table、img，但不支持Flex、Grid、CSS动画、JavaScript。所以被渲染的HTML要保持在“基础固定标签”的范围内，不要指望它在桌面窗口里跑一个完整前端页面。
如果确需显示完整网页，就得用QWebEngineView，它内置Chromium内核，可以渲染现代网页。但代价是打包体积大了很多，内存占用也高。我一般这样取舍：只是展示简单的富文本数据就用QTextBrowser，需要嵌入完整Web应用才用QWebEngineView。这个决策本身也是“固定标签思维”——给每个工具定好固定的使用边界。
4.3 HTML邮件的基础写法：只能用固定标签里的固定标签
HTML邮件是“固定标签”最极端的场景，没有之一。邮件客户端（Outlook、Gmail、网易邮箱）的渲染引擎还停留在十几年甚至二十年前的水平，很多现代CSS根本无效。做HTML邮件，你必须退回最原始的表格布局时代。
我总结的HTML邮件四原则：
第一，邮箱正文不能用外部CSS文件和JavaScript，所有样式只能内联写在标签的style属性里；第二，页面结构只能用table和td布局，不能用float、Flex、Grid；第三，图片必须写固定宽高，而且所有图片要上传到公网可访问的URL，不能用本地路径；第四，整体宽度不要超过600像素，保证在桌面和移动端都能正常显示。
一个最简示例：
<!doctype html> <html lang="zh-cn"> <head> <meta charset="utf-8"> <title>周报</title> </head> <body style="margin: 0; padding: 0; background-color: #f4f4f4;"> <table width="100%" cellpadding="0" cellspacing="0" style="background-color: #f4f4f4;"> <tr> <td align="center"> <table width="600" cellpadding="20" cellspacing="0" style="background-color: #ffffff;"> <tr> <td style="font-size: 20px; font-weight: bold; color: #333;">本周项目概要</td> </tr> <tr> <td style="font-size: 14px; line-height: 1.8; color: #666;"> 这里是邮件正文内容。 </td> </tr> </table> </td> </tr> </table> </body> </html>这种“返祖”式的写法，恰恰是“固定标签让框架更稳固”最好的注脚：在最保守的容器里，只有把结构彻底固定下来，才能换来最广泛的兼容性。每当我在项目里遇到“怎么都用不了新特性”的环境，我就会想起写HTML邮件的日子——然后心态就平衡了。
5. 日常开发中高频标签问题的排查技巧
5.1 字符乱码：先查charset，再查文件编码
乱码八成出在meta charset与文件实际保存编码不一致。排查步骤如下：先打开开发者工具，查看Elements里head的meta标签，确认charset是utf-8；再用编辑器打开HTML源文件，看右下角编码格式是否为UTF-8。两个必须匹配。另外要注意，如果你的页面是用框架动态输出的，还要确认后端接口返回的Content-Type头里charset=utf-8，这三者任意一个不一致都可能乱码。
5.2 图片点击无法弹出图层：检查z-index与定位
前文提到的“img+标签+点击跳出图层”，最常见的实现问题是遮罩层被其他元素盖住。遮罩层要有固定的三层结构：
.mask-layer { position: fixed; top: 0; left: 0; width: 100%; height: 100%; background: rgba(0, 0, 0, 0.6); display: none; align-items: center; justify-content: center; z-index: 9999; }这里有一个关键细节：display: none是隐藏状态，点击小图时改成display: flex，同时给画面加居中定位。遮罩层必须设置z-index，而且要足够大，否则会被其他定位元素盖住。点击遮罩层背景关闭时，要注意阻止事件冒泡：点击图片本身不要关闭，只有点击遮罩层空白处才关闭。做法是在图片上@click.stop或用event.target === 遮罩层元素判断。
5.3 标签嵌套错误导致的样式错乱
浏览器解析HTML有很强的容错能力，会自动帮你补全或修正标签，但这也会掩盖你的错误。比如<p>标签里嵌套<div>，浏览器的解析器会自动切断p标签，把div提到p的外面，最后渲染出的DOM跟你写的HTML完全不一样。这种“表面正常、实际错位”的问题最难排查。
我的建议是写完HTML后，用W3C校验工具或浏览器的Elements面板仔细检查DOM树是否符合预期。不要把“看起来像那么回事”当作成功，DOM树里标签的父子关系、兄弟顺序，才是页面最终的真相。
5.4 常见问题速查表
| 现象 | 大概率原因 | 快速解法 |
|---|---|---|
| 页面文字乱码 | meta charset缺失或与文件编码不一致 | 统一为UTF-8并放在head首位 |
| 图片加载时页面跳动 | img未预留宽高 | 加width/height或aspect-ratio |
| 表单数据提交到后端为空 | input缺少name属性 | 给所有提交类input补name |
| 点击文字无法选中单选/复选框 | label未关联input的id | 用label包裹input或用for指向id |
| 页面没有小屏适配 | 缺少viewport meta | 补上viewport声明 |
| 组件库样式改了没反应 | scoped样式穿透不足 | 使用:deep()深度选择器 |
| 邮箱页面布局乱 | 用了现代CSS布局 | 改为table布局+内联样式 |
| 表格行列错位 | colspan/rowspan计算错误 | 先画网格草稿再写代码 |
| 标题没有在搜索里高亮 | 用了div模拟标题 | 使用真正的h1~h6标签 |
5.5 我常用的三个辅助工具
开发调试固定标签相关的结构问题，我有三个顺手工具：第一个是浏览器的Elements面板，看DOM树比看代码更直观，我几乎每天都要用它检查标签嵌套；第二个是W3C HTML验证器，写完静态页面后跑一遍，能揪出漏掉的闭合标签和非法嵌套；第三个是HTML实体对照表，处理特殊符号显示（比如&、<、>）时随手查一下，避免把符号写成普通文本导致解析异常。
这三个工具本身没什么高深的，但配合“固定标签”的思维，调试效率会提升很多。每次发现标签问题，我会先问自己“为什么这个标签会导致这种现象”，理解了机制以后再修，而不是找到哪儿改哪儿。
6. 把“固定标签”思维带到团队协作中去
6.1 沉淀一套团队统一的HTML骨架模板
固定标签的价值，在团队协作里体现得最明显。一个团队里如果有十个人，就有十种写HTML的习惯：有人喜欢div海，有人喜欢section，有人把样式全写行内，有人连doctype都不写。等到互相review代码时，光理解别人的结构就要花掉大量时间。
我的做法是：在团队文档库里沉淀一份“标准HTML骨架模板”，核心内容包括固定的doctype声明、固定的head元信息顺序、常用的语义标签选用表、通用表单结构示例。新项目一律从这个模板起步；老项目重构页面时，也逐步向这个模板靠拢。这套模板看似增加了“模板成本”，实际上是砍掉了“理解成本”。新人上手时照着模板填空，既不容易写错，也更容易理解别人为什么这么写。
6.2 用标签语义约束代码review的底线
代码review时，我会给团队立三条关于HTML的“红线”：一是禁止用div模拟标题、按钮、链接（特殊情况除外）；二是禁止跳跃标题层级，比如在h2下面直接用h4；三是禁止删掉doctype和charset声明。这三条红线不是限制创造力，而是保护项目的基础稳定性。框架选择可以讨论，业务逻辑可以重构，但标签骨架一旦被破坏，翻修成本极高。
这三条红线我在多个项目里验证过，前期偶尔有人觉得“太死板”，但几个月后大家会发现，页面始终好维护、样式始终可预期、自动化测试始终稳定，这种对比就是“固定标签”最有力的说服。
6.3 从“会写标签”到“懂标签思维”
最后聊聊我对“标签思维”的一点个人看法。会写HTML标签的人很多，但懂“标签思维”的人少。“标签思维”指的是：每写一个标签，都清楚它为什么存在、它应该承载什么内容、它在不同环境和框架下会如何被解析。这种思维不是背熟标签大全就能获得的，它需要在真实项目中反复经历“标签选错→踩坑→排查→修正”的循环，然后慢慢形成本能。
我在招人时，很喜欢问一个问题：如果让你从零搭一个表单页，你会怎么选择input的type？这个问题没有标准答案，但能看出对方是在“套模板”还是在“想原理”。想原理的人会考虑到移动端键盘、浏览器内置校验、表单语义，以及未来维护时别的同事看到这段代码的感受。这种深度思考，才是固定标签背后最值钱的东西。
我在实际开发里还有一个习惯，每次新建页面的时候，会先强制自己把HTML骨架敲一遍，不复制、不粘贴，就那十几行，完完整整打出来。这个习惯保持了快十年，它让基础标签的写法深深刻在我脑子里，无论后来写Vue、React还是小程序，底层的结构感和语义感都没丢过。如果你也想让项目更稳固，不妨从今天开始，重新好好对待你手下的每一个HTML标签。
