做一个用户列表页面，把模块化与语义化搞懂

做一个"用户列表"页面，把模块化与语义化搞懂

1. 项目长什么样

bash 复制代码

proj/
├── readme.md                  # 学习笔记
└── user-chat/
    ├── fe/                    # 前端：只管页面
    │   ├── index.html         #   结构 + 样式
    │   └── common.js          #   行为 + 数据请求
    └── backend/               # 后端：只管数据
        ├── db.json            #   数据源
        └── package.json       #   项目描述文件

前后端分开，各放一个文件夹。前端里 HTML 管结构，JS 管行为，不搅在一起------这就是模块化的起点。

2. 模块化 ------ 为什么要拆

2.1 不拆的后果

把所有代码塞一个文件或几个文件里：

不方便维护：改个样式可能要在一千行代码里翻半天。
不方便扩展：加个新功能，不知道往哪塞，怕碰坏别的东西。
不方便优化：想换一种数据请求方式，结果 HTML、CSS、JS 全耦合在一起。

2.2 怎么拆

两条原则：

原则	做法
每个文件夹有自己的职责	`fe/` 只管页面，`backend/` 只管数据服务
每个文件只做一件事（单一职责）	HTML 管结构，CSS 管样式，JS 管行为

这就是一个类的思想缩小到文件层面。小项目养成习惯，大项目才不会失控。

2.3 前后端分离

scss 复制代码

后端（backend/）                      前端（fe/）
─────────────                        ──────────
db.json                              index.html    ← 结构和样式
   ↓                                      ↓
json-server  →  GET /users  →  fetch()  ← common.js
                  ↑                         ↓
            JSON 数据                  DOM 动态渲染 → 用户看到页面

后端只负责把数据通过 HTTP 暴露出去，前端只负责拿数据渲染页面。两者通过 JSON 格式通信，互不干扰。以后把 json-server 换成 Go/Java 写的真后端，前端代码一行不用改。

3. HTML 语义化 ------ 不要 `<div>` 漫天飞

3.1 两类标签

HTML 标签天然分两种：

类型	特点	适合干什么	例子
块级元素	默认独占一行	做"盒子"、搭布局骨架	`<div>` `<p>` `<h1>` `<section>`
行内元素	可共处一行	装"内容"	`<span>` `<a>` `<em>` `<strong>`

先写盒子（块级），再放内容（行内）------这是拿到设计稿后的第一步思路。

3.2 能叫出名字的标签

<div> 确实能当盒子用，但所有盒子都叫 <div>，等于没分类。语义化标签让你一眼看出每块区域是干嘛的：

html 复制代码

<body>
    <header>  顶部导航区  </header>
    <main>    主体内容区  </main>
    <footer>  底部信息区  </footer>
    <aside>   侧边栏     </aside>
</body>

比 <div class="header"> 好在哪：

机器可读。搜索引擎、浏览器知道这是页头。
人可读。接手代码的人不用翻 CSS 类名就能猜到结构。
大厂面试考这个。语义化是前端基础功的试金石。

3.3 `<table>` 语义的关键 ------ thead + tbody

html 复制代码

<table>
    <thead>              <!-- 表头区域 -->
        <tr>
            <td>ID</td>
            <td>姓名</td>
            <td>家乡</td>
        </tr>
    </thead>
    <tbody>              <!-- 数据区域，JS 动态填充 -->
    </tbody>
</table>

<thead> 和 <tbody> 是 table 语义的精髓。没有它们，浏览器也认 <tr>，但那只是"看起来像表格"，不是"语义上的表格"。加上之后：

浏览器会自动把 thead 固定在顶部（长表格滚动时）。
打印时分页会自动重复表头。
JS 可以精确找到 tbody 来填数据。

4. CSS 布局 ------ container / row / col

4.1 Bootstrap 栅格系统

项目选择用 Bootstrap 3（Twitter 出品），CDN 一行引入：

html 复制代码

<link href="bootstrap.css" rel="stylesheet">

核心三板斧：

ini 复制代码

.container          ← 固定宽度，居中，左右自动留白（适配不同屏幕宽度）
  .row              ← 一行，内部 12 等分
    .col-md-6       ← 占 6/12 = 半宽
    .col-md-offset-3 ← 向右偏移 3 列 → 实现居中

项目中这行代码：

html 复制代码

<div class="row col-md-6 col-md-offset-3">

翻译成人话：一行，占一半宽，再往右推 3 列→居中。

5. 顺便提一嘴 DOM

数据通过 fetch 拿到后，JS 在页面上找到 <tbody> 这个节点，把数据一行行填进去------这就是 DOM 操作。它在整个流程里扮演"把数据变成页面"的最后一步。

javascript 复制代码

fetch 拿数据 → JSON 解析 → document.querySelector 找到 tbody → innerHTML 填入 → 页面更新

这里不展开，详见主页的另一篇《做一个"用户列表"页面，把 DOM 彻底搞懂》

6. HTML 文档的本质

6.1 文本类型

文件本质上都是文本，区别在于类型声明：

类型	说明
`text/plain`	纯文本，记事本打开什么样就什么样
`text/html`	HTML 标签文本，通过 HTTP 传输，浏览器解析为 document

6.2 DOCTYPE

html 复制代码

<!DOCTYPE html> 文档类型声明

! 标记，表示当前是 HTML 最新版本（HTML5），区别HTML4
不加的话浏览器会进怪异模式（Quirks Mode），页面渲染可能出各种奇怪问题

7. 后端 ------ npm 和 json-server

7.1 后端项目从 `package.json` 开始

bash 复制代码

npm init -y

生成 package.json------后端项目的"身份证"，记录：

项目名、版本、描述
依赖了哪些第三方包
启动脚本

7.2 json-server：把 JSON 变成 RESTful API

json 复制代码

// db.json
{
  "users": [
    { "id": 1, "name": "小新", "hometown": "埼玉", "nickname": "马铃薯小鬼" },
    { "id": 2, "name": "阿呆", "hometown": "埼玉", "nickname": "呆神" },
    { "id": 3, "name": "京介", "hometown": "俄罗斯", "nickname": "嘉豪" }
  ]
}

json-server 的约定：顶层 key users 自动变成 GET /users 端点。

json 复制代码

// package.json
"scripts": {
  "dev": "json-server --watch db.json"
}

npm run dev → 服务跑在 localhost:3000 → 前端 fetch 直接拿数据。

一句话：把对象字面量变成了 HTTP 服务。

8. JS 的全栈能力

JS 是这门课里贯穿前后的语言：

前端：document.querySelector、innerHTML、fetch
后端：Node.js + npm + json-server
未来：AI 领域（TensorFlow.js 等）

一套语法，通吃三端。这也是为什么我选择 JS 作为主线语言。

JS语法还有个特点--"松"

8.1 弱类型语言，写起来很随意

在JS中，单引号、双引号、分号、类型声明都不强求

对比强类型语言（Java、Go），JS 不要求你：

声明变量类型------let users = []，不用写 List<User> users
统一引号------单引号、双引号都行
强制分号------不写分号大多数情况下也能跑

好处是上手极快，坏处是写大了容易乱。好在有 TypeScript 可以后天补上类型约束。

8.2 两种 for 循环的取舍

javascript 复制代码

// 传统计数循环
// 快，CPU 计算规则；可读性差了点，太机械了
for (let i = 0; i < users.length; i++) {
    let user = users[i];
}

// ES6 for...of
// js es6 新的for循环 不需要计数
for (let user of users) {
    // 直接用 user，不用管 i
}

对比：

	传统 `for(;;)`	`for...of`
速度	快（CPU 层面就是计数跳转）	略慢（迭代器协议）
可读性	差，"太机械了"	好，意图清晰
需要索引时	天然有 `i`	得自己额外声明
推荐场景	极致性能、需要 `i`	日常遍历，优先用它

日常开发，代码是写给人看的。所以项目里最终选择了 `for...of`。

9. 总结：两个核心 + 三个支撑

css 复制代码

模块化                        语义化
───────                      ───────
前后端分离                    不要 div 漫天飞
文件职责单一                   用正确的标签做正确的事
fe/  vs  backend/             header/main/footer/table

        ↓                       ↓
         CSS 栅格  ────  DOM 操作  ────  npm 后端

模块化管项目怎么组织，越大越重要
语义化管 HTML 怎么写，越好越被大厂看重
CSS 布局、DOM 编程、npm 生态是三个支撑工具，帮你把页面做出来、跑起来

做一个用户列表页面，把模块化与语义化搞懂