从第 01 期开始跟笔记的朋友应该知道，我们是用“拆解页面”的思路来学 HTML 的。这一期进入三个必过的坎：标签之间的关系、HTML 注释、标签属性。这三个东西单独看不难，但它们直接决定你写出来的 HTML 是“能看的结构”还是“能维护的工程”。我不会照着文档念定义，而是把这几年的实际感受和踩坑经验揉进去讲，尽量给到可以直接抄作业的理解方式。
1. HTML标签之间的关系：从“元素嵌套”理解页面骨架
1.1 为什么标签之间会有“关系”
很多新手写 HTML 有一个误区：觉得标签就是按顺序一个个堆上去，<head>写完写<body>，<body>里想到什么标签就写什么标签，写完能出效果就算完事。
但浏览器根本不这么看页面。浏览器渲染 HTML 时，会把每个标签都当做一个节点（node），然后根据标签的先后和嵌套顺序，把这些节点构建成一棵树——这棵树就是 DOM 树（Document Object Model）。
所谓“标签之间的关系”，本质上就是这棵树上节点与节点之间的链接方式。为什么会存在这种关系？因为我们写页面描述的是“结构”，不是“流水账”。举个例子：
<div class="card"> <h2>标题</h2> <p>正文内容</p> </div>这段代码里，<div>把<h2>和<p>包起来了，意味着这两个标签在结构上都隶属于这个<div>。于是浏览器知道“标题和正文属于同一张卡片”。如果只是平铺着写<div>、<h2>、<p>三个各不相干的标签，浏览器不知道如何分组，后面你想给整张卡片加一个边框、统一控制间距，就只能分别给三个标签设置，繁琐且容易遗漏。
所以标签之间的关系，是 HTML 组织信息的核心。理解了这层关系，你就能看懂布局、理解 CSS 选择器的继承逻辑，也才能在后面学习 JavaScript 操作 DOM 时，快速定位到想要的元素。
1.2 三种核心关系：父子、兄弟、祖先后代
具体到实践，标签之间的关系主要有三种。把它类比成一个家庭结构就行。
第一种：父子关系（直接嵌套）
<ul> <li>苹果</li> <li>香蕉</li> </ul>这里的<ul>是父元素，两端的<li>是子元素。判断标准很简单：一个标签的外面紧贴着一层包裹的标签，那里面这个就是直接子级。父子关系是最常见的嵌套关系，通常用来表示“包含”和“从属”。
第二种：兄弟关系（同级并列）
上面例子中的两个<li>，因为同属一个父元素<ul>，它们就是兄弟元素。需要特别注意的是：两个标签之间有空格或换行，不影响兄弟关系；但如果其中一个标签没有正确闭合，兄弟关系就会被打破，这是新手最常踩的坑之一。
<div> <p>第一段</p> <p>第二段</p> </div>两个<p>就是兄弟，它们平级展示。后面学 CSS 时，兄弟选择器h2 + p、h2 ~ p都是建立在“同父兄弟”的基础上。所以这个关系不只是一个理论概念，它是选择器写法的底层依据。
第三种：祖先后代关系（跨层级嵌套）
父子关系是“直接”的，祖先后代是“间接”的。比如：
<section> <div> <p>段落</p> </div> </section><section>是祖先，<p>是后代，中间隔了一个<div>。HTML 中允许跨层引用和操作，CSS 里也常用“后代选择器”（比如.section p），这在调整全局样式时非常方便。但要注意，后代关系范围很大，如果你控制不当，可能会出现“我只想选中某个区块的<p>，结果整个页面的<p>都被影响了”的情况。
为了更直观，我们把关系表格化：
| 关系类型 | 判断方式 | 典型用途 |
|---|---|---|
| 父子关系 | 一个标签直接包裹另一个标签 | 结构化分组、局部布局控制 |
| 兄弟关系 | 多个标签同属一个直接父级 | 并列列表、组合式内容布局 |
| 祖先后代关系 | 跨多层级的包含 | 统一区块样式、事件委托 |
1.3 嵌套关系如何影响页面渲染
说清楚关系之后，要明白一个更实际的问题：这些关系到底会影响什么？
影响一：样式继承。父元素上的某些 CSS 属性，会自动传递给子元素，比如字体大小、字体颜色、行高。如果你在一段内容的外层设置了font-family，里面所有的文本都会继承这个字体，不需要一个个标签去单独设置。这就是父子关系在实践中的最常见体现。
影响二：盒模型布局。父元素的宽度、内边距会直接影响子元素的可用空间。一个常见的问题是：子元素设置了width: 100%，再加上父元素的padding，结果出现横向滚动条。这是因为width: 100%指的是父元素内容区的宽度，而实际渲染时还要加上父元素的 padding 和子元素自身的 border，于是整体超出了视口宽度。理解了父子关系，就能明白“为什么不能无脑用 100%”。
影响三：JavaScript 事件传播。在浏览器里，当我们点击一个子元素时，事件会从子元素一层层向上传递到祖先元素，这个过程叫事件冒泡。如果你对父元素绑定了点击事件，那么点击里面的任意子元素都会触发这个事件。想做事件委托（event delegation），必须先清楚哪些元素之间是父子/祖先后代关系。
影响四：HTML 结构合法性。浏览器容错率很高，标签嵌套错误不会直接导致页面崩溃，但它会“悄悄”帮你重排 DOM 树，导致实际渲染出来的结构和代码里写的不一样。比如在<p>标签里嵌套<div>，浏览器解析时会把<div>“踢”出来，导致页面结构完全出乎意料。
1.4 嵌套关系的三个经典错误
根据我见到的新手代码，有三种嵌套错误出现频率最高：
错误一：块级元素嵌套行内元素不当。典型代表是<p>里面套<div>。规范上<p>是纯文本段落，里面只能放行内内容，硬套<div>会产生意外效果。
错误二：标签未闭合导致兄弟关系错乱。比如写了两个<li>，但第一个漏了闭合标签，浏览器会自动补全，一旦补全的位置不是你想的位置，后续样式和结构全部偏移。调试这种问题最闹心，因为浏览器渲染出来的 DOM 树里，元素层级跟源码长得不一样。
错误三：乱用<div>层层嵌套形成“标签瀑布”。有的写法喜欢用数十层<div>包一个内容区，看起来没有错，但语义混乱，后期维护和样式调试难度直线上升。合适的做法是：优先用语义化标签（<section>、<article>、<aside>），<div>只在需要纯分组时使用。
嵌套关系不是“写对就行”的静态知识，它会影响样式、脚本行为、可访问性等多个层面。后面讲 CSS 和 JavaScript 时，你会不断回头用到这里的理解。
2. HTML注释：一块不会显示在页面上的“便签纸”
2.1 注释的写法与基础语法
注释写起来非常简单：
<!-- 这里是注释内容 -->所有写在<!--和-->之间的文字，浏览器都不会渲染，只在代码源文件里可见。它不会挤占页面空间，也不会影响到任何样式和脚本。
有一个细节值得注意：HTML 注释在浏览器里“不可见”是就渲染结果而言，但在“查看源代码”或者开发者工具里是完全可见的。也就是说，只要是发出去的页面，别人就能通过查看源代码看到你写了什么注释。这一点在工作中要时刻记住：不要在注释里写任何敏感信息、临时账号、开发机地址之类的内幕内容。
注释还有一个特殊用途：能在调试时快速“临时隐藏”一段结构。比如某块区域样式出了问题，你想确认是不是这个结构导致，用注释把这段代码包起来，刷新页面看效果。注意区分：注释隐藏和display: none隐藏是两个层面的事。前者彻底移除渲染输出，后者只是视觉上隐藏但元素仍占据 DOM，事件也仍可绑定。
2.2 注释的实际用途：从“怕忘记”到“沟通协作”
我在实际开发中，注释的用途分成三个层次。
个人备忘层。一个复杂的页面结构，可能包含表格、嵌套区块、长列表。过两个星期你再回来看代码，光看标签很容易忘掉当初每一块是干什么的。注释这时候最省事，直接写明“这是某个模块的头部信息”“这里是商品列表容器”，下次维护不用从头推演。
团队协作层。多个人同时改一个项目是常态。别人看到你的代码，如果没有注释，只能靠猜。合理的注释能让接手的人快速理解区块功能、特殊写法的意图。比如：
<!-- 优惠券区域：两列布局，左列表右详情，逻辑在 assets/js/coupon.js --> <section class="coupon-section"> <!-- ... --> </section>这种注释把结构、布局方式、对应脚本的位置都写清楚了，协作效率会明显提升。
标记待办层。有时候结构写了一半，逻辑还没接上，可以用注释标注 TODO（待办）：
<!-- TODO: 接入后端接口后动态渲染图片列表 --> <div class="product-list"></div>很多编辑器会高亮 TODO 标识，方便后续搜索和跟进。
2.3 注释使用中的注意事项
虽然注释语法简单，但实际用下来有几个地方必须小心。
第一，不要嵌套注释。HTML 注释不支持嵌套。也就是说，你写了一个<!--注释块，里面再写一个<!-- ... -->，第一个注释会在第二个-->处结束，后面的内容可能会暴露出来，引起意外的显示或结构错乱。有些代码编辑器会在语法高亮时提示错误，但新手很容易忽略。
第二，正确使用条件注释的思路已经过时。早年间会看到针对特定浏览器的条件注释，比如<!--[if IE]>这类写法，它只在超老版本的浏览器里有效，现代开发中已完全不用。如果你在项目里看到这类代码，基本是可以直接删除的。
第三，注释不是越多越好。注释应该补充“代码本身表达不了的信息”，而不是复述代码。那些满屏都是<!-- 一个div开始 -->、<!-- 一个div结束 -->的写法，只会让源码更拥挤，阅读体验更差。好的注释，密度低、信息量高，并且永远在描述“为什么这样做”而不是“做了什么”。
从工程角度说，注释写得好坏，是一个人代码习惯和专业度的直接体现。它不会影响功能，但会影响所有后面维护代码的人的心情和效率，包括未来的你自己。
3. 标签属性：让同一个标签适应不同需求的“调节旋钮”
3.1 属性的基本结构
标签负责定义“这是一个什么元素”，属性则负责定义“这个元素如何表现、有哪些额外信息”。它的基本写法是：在开始标签里写空格，属性名后面跟一个等号，等号后面跟一个引号（单引号双引号皆可，但行业内默认用双引号），引号内写属性值。
<a href="https://example.com" title="示例链接">这是一个链接</a>href是属性名，https://example.com是属性值。多个属性之间用空格分隔。属性与属性之间的顺序不影响结果，但一定都要写在开始标签里，结束标签里不能写属性。
属性值用什么引号？我建议统一用双引号。虽然 HTML5 官方允许部分属性值在特定情况下不加引号，但那是语法层面的“允许”，不是工程层面的“推荐”。真实项目里属性值经常会包含空格、特殊字符，不加引号就会导致浏览器解析错误。统一用双引号还能减少团队协作时格式不一致的麻烦。
3.2 常见全局属性详解
有些属性是某些标签专有的，比如href属于<a>，src属于<img>、<script>等。但还有一组“全局属性”，几乎可以用在任意标签上。这几种是我日常用的最多的：
id：页面上唯一的身份标识。同一个页面中id值不能重复。它一般用于锚点跳转、CSS 精确定位、JavaScript 绑定操作。非常不建议把它当普通样式钩子用得太多，因为它是全局唯一，复用性差。
class：样式类名，可重复。一个元素可以写多个类名，不同类名用空格分隔。这是 CSS 样式化时最核心的属性。它的语义是“这个元素属于哪些类”，一个类对应一组样式规则。值得提醒的是，类名命名要语义化，比如.product-card比.div1好一万倍——前者一看就知道是商品卡片，后者对维护者毫无意义。
style：行内样式。直接在标签上写 CSS 属性，比如style="color: red"。它的优先级最高，会覆盖外部样式和内部样式中的同名属性。但工程上要谨慎使用，因为它会让样式难以复用，也不好维护，一般只在测试、临时调试或极少数动态样式场景中才会用到。
title：悬停提示文本。鼠标悬停在元素上时，浏览器会显示小气泡提醒。它主要用于补充说明，比如一个不常见的缩写，或者一个图标的含义。但要注意，移动端没有鼠标悬停，悬停提示基本失效，所以不能让关键信息只存在于title里。
上面三种写法，在浏览器里全部都是禁用的。很多人第一次遇到会在 类似的布尔属性还有 注意规则：HTML 中属性名是 这行代码会在 DOM 上新增或更新 输出结果里应该有 整理一下这几类问题，基本覆盖了我见过的大多数初学者困惑： 表格：问题、原因、解决思路 这段样式会把页面上所有元素都框出来，一眼就能看到嵌套层次。排查完立刻删掉，不要留着。 写 HTML 这玩意儿，短期看语法，长期看工程习惯。这一期里讲的标签关系、注释和属性，背后都有一个共同点：它们都是“给人读、给浏览器读、给未来的维护者读”的代码。你可以写出能跑的页面，但那离“写得好”还有一段路。 第一个建议：写结构之前，先画草图。哪怕只是在纸上画几个方块，标出“这块包含那块、那块和那块并列”，也比直接敲代码强。很多嵌套关系错乱，根源是设计阶段就没有想清楚哪一层是什么。草图不是浪费时间，它是在为你省未来调样式的时间。 第二个建议：注释要“跟着意图走”，不要“跟着代码走”。代码变更后，注释忘记更新是最常见的问题。一个注释写的是“展示用户列表”，但代码已经改成“展示筛选后的用户列表”，这种过期注释在团队协作里非常容易误导人。修改代码时，顺手把相关注释也过一遍，这不是可做可不做的事，是基本职业习惯。 第三个建议：属性命名要有约定。尤其是 演示声明：本文的 NoteBudget、NoteReviewPage、任务 NB-3311、全部页面图、DevEco Studio 外观图和 HiLog 行，均是为解释工程设计而制作的静态演示。没有声称完成 DevEco 编译、模拟器运行、真机测试、后台提交或上架审核。一、交接备注不长，…
简介：面向ArcGIS数据整合与建库场景，这款基于arcpy开发的GDB批量合并工具，可帮助空间数据管理人员快速归并同一目录下多个文件地理数据库，同名要素类自动合并到目标GDB，摆脱逐层手动导入导出的繁琐流程。工具以两个工具…
人工智能AI AgentAgent 框架后端工具调用 【免费下载链接】eve The Open Framework for Building Agents 项目地址： https://gitcode.com/gh_mirrors/eve28/eve 点击查看 免费下载 本文是 eve 开源框架（The Open Framework for Building Agents…
1. 项目背景与核心价值微电网作为分布式能源的重要载体，正在重塑传统电力系统的运行模式。但风光等可再生能源的波动性和负荷不确定性，给微电网的稳定运行带来了巨大挑战。三年前我在参与一个海岛微电网项目时，就曾亲眼目睹过由于预测偏差导致…
1. 在线培训系统的时代价值去年帮一家200人规模的科技公司部署在线培训系统时，他们的HR总监给我算过一笔账：传统线下培训每月要消耗37个工时在场地协调和差旅安排上，而采用我们的系统后，第一季度就完成了全年82%的培训指标。这让我…
1. 项目缘起与整体分析框架1.1 为什么选长租公寓投诉数据作为分析标的长租公寓这个行业在过去几年经历了过山车式的变化，头部品牌暴雷、租金贷风波、房东与租客两头受损的新闻层出不穷。我之所以挑蛋壳公寓的投诉数据来做这个分析项目，原因很直接&#x…
><button><input type="text" disabled> <input type="text" disabled="disabled"> <input type="text" disabled="false">disabled="false"那里纠结半天，以为写了false就能启用，实际上根本没用。要启用输入框，必须直接移除disabled属性，用element.removeAttribute('disabled')或者element.disabled = false。readonly、checked、selected、required、autofocus等。记住这个规则就好：在 HTML 里，属性的存在本身就是“真”。如果后续要用 JavaScript 操作这些属性，也不要尝试动态修改“属性值”来开关，要直接增删属性。3.4 自定义属性><div class="task-item">const items = document.querySelectorAll('.task-item'); items.forEach(item => { console.log(item.dataset.id); // '101' '102' console.log(item.dataset.status); // 'done' 'pending' });
>item.dataset.status = 'completed';><div class="page-wrap"> <header class="page-header"> <h1>任务看板</h1> </header> <section class="task-board"> <div class="task-item"><!-- 页面总容器：控制整体宽度与最小高度 --> <div class="page-wrap"> <!-- 头部区域：包含页面说明文字，样式统一由 .page-header 控制 --> <header class="page-header"> <h1>任务看板</h1> </header> <!-- 任务面板：循环渲染多个任务卡片，数据来自 tasks.js --> <section class="task-board"> <div class="task-item">document.querySelector('.task-item').datasetid: "201"和status: "pending"。如果输出undefined，那就要检查属性名拼写是否一致，尤其是横线转驼峰的规则。5. 常见问题排查速查表
5.1 新手高频问题
问题现象 可能原因 解决思路 某个区块的样式没生效 标签关系与选择器不匹配 检查是父级还是后代，改用对应选择器 页面出现意外空行或换行 注释包裹了部分结构或标签缺失闭合 查看源码，检查注释范围，补齐闭合 点击按钮无效 disabled="false"误以为已启用记住布尔属性存在即生效，直接删除属性 JavaScript 读到 undefined>/* 临时排查用，别提交到生产 */ * { outline: 1px solid rgba(255, 0, 0, 0.3); }6. 长期实践中的几点建议
class和>
ArkUI TextArea：交接备注UTF-8字节预算草稿预警与提交门禁【鸿蒙心迹】
ArcPy批量合并GDB：字段映射、坐标系与容错处理实战解析
eve Tasks 升级指南：从 `execution: “background“`、`agentId` 与 `subagent.*` 事件完整迁移到 Tasks
微电网模型预测控制(MPC)的Python实现与优化
的Python实现与优化)
企业在线培训系统架构设计与实践指南
基于蛋壳公寓投诉数据的文本分析与可视化实战
