产品 / 文章评论回复：数据库设计与代码实现指南

评论系统看起来像「树」，很多人第一反应是把 SQL 写得很复杂，甚至用递归 CTE 一次查出整棵树。实际工程里更稳妥的做法往往相反：

数据库只存扁平关系，一次简单 SQL 查出当前目标下的全部有效评论，再由后端根据 parent_id 组装成树，前端递归渲染。

本文以商品 SKU 评论为例，同时说明这套设计如何直接套用到文章、帖子、工单等场景。配套代码见同目录下的 test.py。

1. 要解决什么问题

一个商品（或一篇文章）上，用户可以发一级评论；其他用户可以对某条评论再回复。回复还可以继续被回复，于是自然形成树：

商品 100
├── 评论 1：这个商品真的不错！
│   ├── 回复 2：确实不错，我也买了一个。
│   │   ├── 回复 3：我也是，使用体验很好。
│   │   └── 回复 9：这个商品真的不错！
│   └── 回复 8：这个商品真的不错！
├── 评论 4：价格怎么样？
│   └── 回复 5：我买的时候是 199 元。
│       └── 回复 6：现在好像降价了。
└── 评论 7：现在好像降价了。

系统要同时满足：

写入简单：发评论、回评论都是插入一行
读取清晰：详情页能拿到「一级评论 + 嵌套回复」
结构稳定：以后支持多级回复时，不必改表
SQL 简单：不要为了「树」把查询写得难以维护

2. 核心设计：邻接表（Adjacency List）

每条评论只记住自己的直接父评论。这就是邻接表：

字段	含义
`id`	当前评论
`parent_id`	直接父评论；`NULL` 表示一级评论
`product_id` / `article_id`	这条评论挂在哪个业务对象上

它不在数据库里存整棵树，只存「谁回复了谁」。树是读出来之后，在内存里拼出来的。

对应关系非常直观：

id          parent_id
---------------------
1           NULL          ← 一级评论
2           1             ← 回复评论 1
3           2             ← 回复评论 2
4           NULL          ← 另一条一级评论

拼出来就是：

1
└── 2
    └── 3
4

3. 数据表设计

3.1 商品评论表

下面这张表已经足够覆盖「评论 + 多级回复」：

CREATE TABLE `product_comment` (
  `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT COMMENT '主键',
  `product_id` bigint(20) unsigned NOT NULL COMMENT '产品ID',
  `user_id` bigint(20) unsigned NOT NULL COMMENT '评论用户ID',
  `parent_id` bigint(20) unsigned DEFAULT NULL COMMENT '父评论ID，空表示一级评论',
  `content` varchar(500) COLLATE utf8mb4_unicode_ci NOT NULL COMMENT '评论内容',
  `status` tinyint(3) unsigned NOT NULL DEFAULT '1' COMMENT '1正常 0删除',
  `created_at` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '评论时间',
  PRIMARY KEY (`id`),
  KEY `idx_product_created` (`product_id`,`status`,`created_at`),
  KEY `idx_parent_id` (`parent_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci COMMENT='产品评论';

字段职责：

product_id：这条评论属于哪个商品。查询某个商品的全部评论，靠它过滤。
user_id：谁发的。展示头像、昵称时再关联用户表。
parent_id：整棵树的关键。NULL 是根节点（一级评论），非空则指向直接父评论。
content：评论正文。长度按业务定，商品评论 500 字通常够用。
status：软删除。0 表示删除，查询时过滤掉，历史回复关系还能保留。
created_at：排序用。详情页一般按时间正序或倒序展示。

索引为什么这样建：

idx_product_created (product_id, status, created_at)：详情页最常见的查询是「某商品、未删除、按时间排序」。三个字段放在一起，能覆盖 WHERE product_id = ? AND status = 1 ORDER BY created_at。
idx_parent_id (parent_id)：按父评论拉回复、校验父评论是否存在时有用。评论量不大时不是瓶颈，但成本很低，建议保留。

3.2 文章评论怎么套用

把 product_id 换成 article_id 即可，其余字段完全一样：

CREATE TABLE `article_comment` (
  `id` bigint unsigned NOT NULL AUTO_INCREMENT COMMENT '主键',
  `article_id` bigint unsigned NOT NULL COMMENT '文章ID',
  `user_id` bigint unsigned NOT NULL COMMENT '评论用户ID',
  `parent_id` bigint unsigned DEFAULT NULL COMMENT '父评论ID，空表示一级评论',
  `content` varchar(2000) NOT NULL COMMENT '评论内容',
  `status` tinyint unsigned NOT NULL DEFAULT 1 COMMENT '1正常 0删除',
  `created_at` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '评论时间',
  PRIMARY KEY (`id`),
  KEY `idx_article_created` (`article_id`, `status`, `created_at`),
  KEY `idx_parent_id` (`parent_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci COMMENT='文章评论';

如果希望商品、文章、帖子共用一张评论表，可以做成更通用的形态：

CREATE TABLE `comment` (
  `id` bigint unsigned NOT NULL AUTO_INCREMENT,
  `target_type` varchar(32) NOT NULL COMMENT 'product / article / post',
  `target_id` bigint unsigned NOT NULL COMMENT '业务对象 ID',
  `user_id` bigint unsigned NOT NULL,
  `parent_id` bigint unsigned DEFAULT NULL,
  `content` varchar(2000) NOT NULL,
  `status` tinyint unsigned NOT NULL DEFAULT 1,
  `created_at` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP,
  PRIMARY KEY (`id`),
  KEY `idx_target_created` (`target_type`, `target_id`, `status`, `created_at`),
  KEY `idx_parent_id` (`parent_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci COMMENT='通用评论';

业务初期更推荐分表：商品评论一张表、文章评论一张表。查询更直观，索引更好建，也不会因为不同类型评论量差异太大而互相拖累。等评论能力完全统一、业务对象继续增多时，再考虑通用表。

3.3 可选扩展字段

当前表已经能跑通评论回复。下面这些字段不是必须，但真实产品里经常会补：

字段	作用
`root_id`	指向所属一级评论。分页、按楼折叠时非常有用
`reply_to_user_id`	被回复的用户。前端展示「回复 @张三」
`like_count`	点赞数。避免每次 COUNT 关联表
`reply_count`	直接回复数或整楼回复数
`updated_at`	编辑时间
`ip` / `user_agent`	风控、审计

注意：root_id 和 parent_id 职责不同。

parent_id：直接父节点，用来建树
root_id：这条回复属于哪条一级评论，用来按楼查询

例如：

评论 A   id=1  parent_id=NULL  root_id=1
  回复 B id=2  parent_id=1     root_id=1
    回复 C id=3 parent_id=2    root_id=1

C 的直接父亲是 B，但整条楼都挂在 A 下面。详情页「只展开某一楼的回复」时，用 root_id = 1 一次查出该楼全部回复，比沿着 parent_id 递归查更简单。

初期没有分页压力，可以先不加重 root_id。等单商品评论变多，再补字段、做一次回填即可。

4. 最重要的约定：`parent_id` 永远指向直接父评论

必须写进接口文档和代码注释：

parent_id 永远指向直接父评论。一级评论的 parent_id 为 NULL。

正确：

评论 A    id=1  parent_id=NULL
  回复 B  id=2  parent_id=1
    回复 C id=3 parent_id=2

错误：把 C 也指向 A：

评论 A    id=1  parent_id=NULL
  回复 B  id=2  parent_id=1
  回复 C  id=3  parent_id=1     ← C 其实是回复 B 的，却挂到了 A 上

第二种写法在「只允许一级回复」时看起来也能用，但会丢掉「谁回复了谁」。前端只能显示「都在 A 楼下」，无法显示「C 回复了 B」。多级回复一旦出现，树就会乱。

写入时还要校验：

parent_id 为空：这是一级评论，合法。
parent_id 不为空：父评论必须存在、未删除，且和当前评论属于同一个 product_id / article_id。
不允许把评论挂到别的商品的评论下面。

5. 读取：保持 SQL 简单

详情页读取某个商品的评论，推荐这一条：

SELECT
    c.id,
    c.product_id,
    c.user_id,
    c.parent_id,
    c.content,
    c.created_at,
    u.nickname,
    u.avatar
FROM product_comment c
LEFT JOIN users u ON u.id = c.user_id
WHERE c.product_id = 2
  AND c.status = 1
ORDER BY c.created_at ASC;

这条 SQL 只做三件事：

限定商品
过滤已删除
带上用户昵称、头像，按时间排序

它不负责建树。建树交给 Python。

为什么这样更好：

意图清晰：DBA、后端、前端都能一眼看懂
走索引：idx_product_created 正好覆盖
和层级数无关：以后从「只允许回复一级」改成「允许无限级」，SQL 不用改
易于测试：先看扁平结果对不对，再看树对不对

数据库返回的是扁平列表：

id   product_id   user_id   parent_id   content
2    2            1         NULL        金轩求报价，我我。
3    2            2         2           私信写回，还利两张。
4    2            3         NULL        太好看了，已关注店铺。

后端组装后，接口返回树：

[
  {
    "id": 2,
    "content": "金轩求报价，我我。",
    "user": { "id": 1, "nickname": "张三" },
    "children": [
      {
        "id": 3,
        "content": "私信写回，还利两张。",
        "user": { "id": 2, "nickname": "李四" },
        "children": []
      }
    ]
  },
  {
    "id": 4,
    "content": "太好看了，已关注店铺。",
    "user": { "id": 3, "nickname": "王五" },
    "children": []
  }
]

5.1 为什么不直接用 SQL 查成树

MySQL 8 可以用递归 CTE 查树，自连接也可以把「评论 + 一级回复」拼成宽表。这些写法在演示里好看，工程里通常更难维护：

递归 CTE 对层级、性能、分页都不友好
自连接只适合「固定一层回复」；一旦出现回复的回复，SQL 就要改
结果集是宽表或重复行，还是得在代码里再归并

评论量正常时（一个商品几百、几千条），一次查出来再在 Python 里 O(n) 建树，足够快，也最好懂。

5.2 只有一层回复时，自连接也可以

如果产品明确约束「只能回复一级评论，不能再回复回复」，可以用自连接：

SELECT
    c.id AS comment_id,
    c.content AS comment_content,
    c.created_at AS comment_created_at,
    r.id AS reply_id,
    r.content AS reply_content,
    r.created_at AS reply_created_at
FROM product_comment c
LEFT JOIN product_comment r
    ON r.parent_id = c.id
   AND r.status = 1
WHERE c.product_id = 2
  AND c.parent_id IS NULL
  AND c.status = 1
ORDER BY c.created_at ASC, r.created_at ASC;

结果类似：

comment_id | comment_content           | reply_id | reply_content
-----------+---------------------------+----------+--------------
2          | 金轩求报价，我我。         | 3        | 私信写回，还利两张。
4          | 太好看了，已关注店铺。     | NULL     | NULL

一条一级评论若有 3 条回复，就会出现 3 行。后端还是要按 comment_id 归并。和「查扁平列表再建树」相比，收益不大，灵活性更差。除非业务永远只有一层回复，否则不建议把这当成主方案。

6. 后端建树：`test.py` 代码分析

test.py 把「数据库查出来的扁平评论」组装成树，是整套方案里最关键的一段逻辑。建议先跑一遍：

uv run python test.py

6.1 测试数据在模拟什么

comments = [
    {"id": 1, "product_id": 100, "user_id": 1, "parent_id": None, "content": "这个商品真的不错！"},
    {"id": 2, "product_id": 100, "user_id": 2, "parent_id": 1,    "content": "确实不错，我也买了一个。"},
    {"id": 3, "product_id": 100, "user_id": 3, "parent_id": 2,    "content": "我也是，使用体验很好。"},
    {"id": 4, "product_id": 100, "user_id": 4, "parent_id": None, "content": "价格怎么样？"},
    {"id": 5, "product_id": 100, "user_id": 5, "parent_id": 4,    "content": "我买的时候是 199 元。"},
    {"id": 6, "product_id": 100, "user_id": 6, "parent_id": 5,    "content": "现在好像降价了。"},
    {"id": 7, "product_id": 100, "user_id": 6, "parent_id": None, "content": "现在好像降价了。"},
    {"id": 8, "product_id": 100, "user_id": 1, "parent_id": 1,    "content": "这个商品真的不错！"},
    {"id": 9, "product_id": 100, "user_id": 1, "parent_id": 2,    "content": "这个商品真的不错！"},
]

这就是 SELECT ... WHERE product_id = 100 AND status = 1 ORDER BY created_at ASC 的结果：一维列表，每条记录只知道自己的 parent_id。

对应关系：

id=1  parent_id=None     一级评论
id=2  parent_id=1        回复 1
id=3  parent_id=2        回复 2
id=4  parent_id=None     一级评论
id=5  parent_id=4        回复 4
id=6  parent_id=5        回复 5
id=7  parent_id=None     一级评论
id=8  parent_id=1        回复 1
id=9  parent_id=2        回复 2

注意几点：

同一条一级评论可以有多条直接回复：id=2 和 id=8 都挂在 id=1 下
同一条回复也可以继续被多人回复：id=3 和 id=9 都挂在 id=2 下
id=7 的内容和 id=6 相同，但 parent_id 不同：一个是一级评论，一个是嵌套回复。内容相同不代表结构相同，父子关系只看 parent_id。

6.2 建树函数拆成三步

def build_comment_tree(comments):
    for comment in comments:
        comment["children"] = []

    comment_map = {
        comment["id"]: comment
        for comment in comments
    }

    tree = []

    for comment in comments:
        parent_id = comment["parent_id"]

        if parent_id is None:
            tree.append(comment)
        else:
            parent = comment_map.get(parent_id)
            if parent:
                parent["children"].append(comment)

    return tree

第一步：给每条评论预留 `children`

树节点需要一个数组装子评论。先统一初始化，后面只做「往数组里 append」，不会在循环里反复判断字段是否存在。

这一步会原地修改传入的 dict。如果后续还要保留「扁平列表」做别的用途，应先拷贝再建树：

import copy

def build_comment_tree(comments):
    comments = copy.deepcopy(comments)
    ...

接口场景里，查询结果通常用完即弃，原地改更直接。

第二步：建立 `id -> 评论对象` 的索引

comment_map = {
    comment["id"]: comment
    for comment in comments
}

得到：

{
    1: 评论1对象,
    2: 评论2对象,
    ...
    9: 评论9对象,
}

这里存的是对象引用，不是拷贝。后面把评论 2 放进评论 1 的 children 时，改的就是同一块内存。因此 comment_map[1]["children"] 和最终树里那条评论 1 的 children 是同一份数据。

有了这张 map，找父评论是 O(1)，不必每次都扫一遍列表。

第三步：一遍扫描，挂到父亲或作为根

对每条评论：

parent_id is None：它是一级评论，放进 tree
否则：用 comment_map.get(parent_id) 找到父亲，append 到父亲的 children

get 而不是直接 [] 取值，是为了防御脏数据：父评论被删了、或查询时被 status = 1 滤掉了，子评论就会变成孤儿。这里选择「找不到父亲就丢弃」。也可以改成「降级成一级评论」或「记一条告警」，按产品决定。

6.3 为什么顺序是对的

SQL 已经 ORDER BY created_at ASC。build_comment_tree 是按列表顺序遍历的：

先遇到的一级评论，先进入 tree
先遇到的子评论，先进入某个父亲的 children

因此最终树保留了时间顺序，函数本身不必再排序。如果产品要「一级评论按时间倒序，回复仍按正序」，可以：

SQL 仍按 created_at ASC 查出全部回复，保证子节点顺序
只把 tree 反转：tree.reverse()
或者一级评论单独倒序查，回复再按 parent_id / root_id 补齐

6.4 实际运行结果

ID=1 parent_id=None 这个商品真的不错！
    ID=2 parent_id=1 确实不错，我也买了一个。
        ID=3 parent_id=2 我也是，使用体验很好。
        ID=9 parent_id=2 这个商品真的不错！
    ID=8 parent_id=1 这个商品真的不错！
ID=4 parent_id=None 价格怎么样？
    ID=5 parent_id=4 我买的时候是 199 元。
        ID=6 parent_id=5 现在好像降价了。
ID=7 parent_id=None 现在好像降价了。

打印函数本身也是递归：

def print_tree(comments, level=0):
    for comment in comments:
        indent = "    " * level
        print(f"{indent}ID={comment['id']} parent_id={comment['parent_id']} {comment['content']}")
        if comment["children"]:
            print_tree(comment["children"], level + 1)

前端渲染评论列表时，用的也是同样的递归思路：先画当前节点，再画 children。

6.5 复杂度

设一个商品有 n 条有效评论：

初始化 children：O(n)
建 map：O(n)
扫描挂载：O(n)

整体 O(n)，额外空间主要是那张 map，也是 O(n)。一个商品几百、几千条评论，在 Python 里几乎可以忽略。真正要小心的是「一个商品几万条评论还一次全查」——那是分页问题，不是建树算法问题。

6.6 这段代码的两个细节

1. 不要在遍历时按「层级」一层层找。

错误直觉是：先找所有 parent_id is None，再找它们的孩子，再找孙子。那样每一层都要扫全表，最坏 O(n²)，代码也更绕。当前写法只扫一遍，任意深度都能挂上。

2. 父评论可以出现在子评论后面吗？

可以。因为先建了完整 comment_map。即使列表顺序是「先子后父」，parent_id=1 时也能立刻拿到评论 1 的对象，把子评论 append 进去。根节点进入 tree 的顺序仍取决于一级评论在原列表中的位置。

所以这个算法不依赖「父亲一定排在儿子前面」。ORDER BY created_at ASC 只是为了展示顺序，不是算法正确性的前提。当然，正常业务里父亲一定更早创建，按时间正序时父亲几乎总在前面。

7. 推荐的整体数据流

商品详情 / 文章详情
        ↓
SELECT 该 product_id / article_id 的全部有效评论
（简单 SQL，LEFT JOIN 用户表）
        ↓
得到扁平列表
        ↓
Python 根据 parent_id 组装树
        ↓
返回 JSON
        ↓
前端递归渲染

接口可以设计成：

GET /api/products/{product_id}/comments
GET /api/articles/{article_id}/comments

发表评论：

POST /api/products/{product_id}/comments
Content-Type: application/json

{
  "content": "这个商品真的不错！",
  "parent_id": null
}

回复评论：

POST /api/products/{product_id}/comments
Content-Type: application/json

{
  "content": "确实不错，我也买了一个。",
  "parent_id": 1
}

删除走软删除：

DELETE /api/products/{product_id}/comments/{comment_id}

对应 SQL：

UPDATE product_comment
SET status = 0
WHERE id = ?
  AND product_id = ?
  AND user_id = ?;

软删除后，查询带 status = 1，已删评论不会出现在树上。它的子回复如果还是 status = 1，会变成孤儿。产品上通常有两种处理：

删评论时级联软删整棵子树
保留子回复，展示「该评论已删除」，子回复仍可见

前者实现简单，后者体验更好。若选后者，建树时找不到父亲，就不要丢弃子评论，而是挂一个占位根，或显示「回复的原评论已删除」。

8. FastAPI 落地示例

下面是接近生产的最小实现，突出「简单 SQL + 内存建树」。用户表、鉴权按项目替换即可。

from typing import Optional

from fastapi import FastAPI, HTTPException
from pydantic import BaseModel, Field
from sqlalchemy import text
from sqlalchemy.ext.asyncio import AsyncSession

app = FastAPI()


class CommentCreate(BaseModel):
    content: str = Field(min_length=1, max_length=500)
    parent_id: Optional[int] = None


def build_comment_tree(comments: list[dict]) -> list[dict]:
    for comment in comments:
        comment["children"] = []
        comment["user"] = {
            "id": comment.pop("user_id"),
            "nickname": comment.pop("nickname"),
            "avatar": comment.pop("avatar"),
        }

    comment_map = {comment["id"]: comment for comment in comments}
    tree: list[dict] = []

    for comment in comments:
        parent_id = comment["parent_id"]
        if parent_id is None:
            tree.append(comment)
            continue

        parent = comment_map.get(parent_id)
        if parent:
            parent["children"].append(comment)

    return tree


LIST_SQL = """
SELECT
    c.id,
    c.product_id,
    c.user_id,
    c.parent_id,
    c.content,
    c.created_at,
    u.nickname,
    u.avatar
FROM product_comment c
LEFT JOIN users u ON u.id = c.user_id
WHERE c.product_id = :product_id
  AND c.status = 1
ORDER BY c.created_at ASC
"""


@app.get("/api/products/{product_id}/comments")
async def list_comments(product_id: int, db: AsyncSession):
    result = await db.execute(text(LIST_SQL), {"product_id": product_id})
    rows = [dict(row) for row in result.mappings()]
    return build_comment_tree(rows)


INSERT_SQL = """
INSERT INTO product_comment (product_id, user_id, parent_id, content)
VALUES (:product_id, :user_id, :parent_id, :content)
"""

PARENT_SQL = """
SELECT id, product_id, status
FROM product_comment
WHERE id = :parent_id
"""


@app.post("/api/products/{product_id}/comments")
async def create_comment(
    product_id: int,
    body: CommentCreate,
    db: AsyncSession,
    user_id: int,
):
    if body.parent_id is not None:
        result = await db.execute(text(PARENT_SQL), {"parent_id": body.parent_id})
        parent = result.mappings().first()
        if parent is None or parent["status"] != 1:
            raise HTTPException(status_code=400, detail="父评论不存在或已删除")
        if parent["product_id"] != product_id:
            raise HTTPException(status_code=400, detail="不能回复其他商品的评论")

    await db.execute(
        text(INSERT_SQL),
        {
            "product_id": product_id,
            "user_id": user_id,
            "parent_id": body.parent_id,
            "content": body.content,
        },
    )
    await db.commit()
    return {"ok": True}

文章评论把 product_id 换成 article_id、表名换成 article_comment，build_comment_tree 可以原样复用。

9. 前端怎么渲染

树已经在后端拼好，前端不必再自己按 parent_id 分组。Vue 递归组件示意：

<!-- CommentItem.vue -->
<template>
  <div class="comment">
    <img :src="comment.user.avatar" alt="" />
    <div>
      <strong>{{ comment.user.nickname }}</strong>
      <p>{{ comment.content }}</p>
      <small>{{ comment.created_at }}</small>
      <button @click="reply(comment.id)">回复</button>

      <div v-if="comment.children.length" class="children">
        <CommentItem
          v-for="child in comment.children"
          :key="child.id"
          :comment="child"
          @reply="reply"
        />
      </div>
    </div>
  </div>
</template>

列表页：

<CommentItem
  v-for="comment in comments"
  :key="comment.id"
  :comment="comment"
/>

这和 test.py 里的 print_tree 是同一件事：当前节点 + 递归子节点。

有些产品在 UI 上不展示真正的多级缩进，而是「一级评论 + 扁平回复列表」，回复里带「回复 @某人」。那是展示层的选择，数据库仍然建议存直接父评论。扁平展示时，后端可以把某楼的 children 再拍平，并带上 reply_to_user。

10. 评论量变大之后怎么查

「一次查出该商品全部评论再组树」适合评论量可控的详情页。单个商品到几万条时，全量查询和整棵 JSON 都会成为问题。这时不要把 SQL 写复杂，而是改查询范围。

10.1 一级评论分页，回复按需加载

列表接口只查一级评论：

SELECT
    c.id,
    c.product_id,
    c.user_id,
    c.parent_id,
    c.content,
    c.created_at,
    u.nickname,
    u.avatar
FROM product_comment c
LEFT JOIN users u ON u.id = c.user_id
WHERE c.product_id = :product_id
  AND c.parent_id IS NULL
  AND c.status = 1
ORDER BY c.created_at DESC
LIMIT :limit OFFSET :offset;

点开某一楼时，再查该楼回复。若有 root_id：

SELECT
    c.id,
    c.parent_id,
    c.content,
    c.created_at,
    u.nickname,
    u.avatar
FROM product_comment c
LEFT JOIN users u ON u.id = c.user_id
WHERE c.root_id = :root_id
  AND c.id <> :root_id
  AND c.status = 1
ORDER BY c.created_at ASC;

没有 root_id 时，只能按 parent_id 一层层查，或查该商品全部评论后再在内存里筛某一棵子树。所以评论量上来后，root_id 的价值会明显增加。

10.2 一级评论带上「前几条回复」

详情页常要：每条一级评论先展示 2～3 条回复，其余点「展开」。实现方式：

分页查出一级评论 ID 列表
用这些 ID 再查回复（parent_id IN (...) 或 root_id IN (...)）
内存建树，每棵树只切前 N 条回复

这仍然是「简单 SQL + 内存组装」，只是从「一个商品全量」变成「当前页相关的那几棵小树」。

11. 写入、校验与删除要注意的点

11.1 发表一级评论

INSERT INTO product_comment (product_id, user_id, parent_id, content)
VALUES (100, 1, NULL, '这个商品真的不错！');

11.2 发表回复

INSERT INTO product_comment (product_id, user_id, parent_id, content)
VALUES (100, 2, 1, '确实不错，我也买了一个。');

写入前确认：

父评论存在且 status = 1
父评论的 product_id 与当前请求一致
content 非空、长度合法、过一次敏感词
登录用户才能发（user_id 来自 token，不要信任前端传的 user_id）

11.3 不要让树形成环

正常按时间插入不会成环。如果以后支持「修改 parent_id」或数据修复脚本，必须禁止：

parent_id = 自己的 id
A 的父亲是 B，B 的父亲又是 A

建树是普通循环，不是无限递归，环不会把 Python 绕死，但会让某条评论既不在根上、又挂错位置，表现为「评论消失」。数据修复时可以用访问过的 id 集合做环检测。

11.4 `parent_id` 建议加外键吗

可以：

CONSTRAINT `fk_comment_parent`
  FOREIGN KEY (`parent_id`) REFERENCES `product_comment` (`id`)

好处是数据库层阻止指向不存在的父亲。坏处是硬删除父评论时要处理子行，软删除场景下外键帮助有限。很多业务系统选择应用层校验 + 软删除，不加自关联外键。两种都可以，关键是写入路径必须校验父评论。

12. 常见误区

误区 1：为了树去写复杂 SQL。
详情页评论量不大时，简单 SELECT 加 Python 组树是更清晰的方案。

误区 2：parent_id 一律指向一级评论。
这样只能表达「在哪一楼」，不能表达「回复了谁」。多级回复会丢信息。

误区 3：用内容去推断层级。
test.py 里 id=6 和 id=7 内容相同，一个是回复，一个是一级评论。层级只认 parent_id。

误区 4：在循环里反复扫描找儿子。
先建 id -> 对象 的 map，再一遍挂载，才是 O(n)。

误区 5：过早上递归 CTE、闭包表、物化路径。
邻接表已经能覆盖绝大多数商品评论、文章评论。等单目标评论到万级、且要频繁做「查整棵子树 / 查所有祖先」时，再考虑 root_id、闭包表等增强。

误区 6：硬删除。
直接 DELETE 会让子评论的 parent_id 悬空。用 status 软删除，再决定是否级联。

13. 和 `test.py` 对照的最小心智模型

把整套方案收成四句话：

表是扁平的：一行一条评论，parent_id 指向直接父亲。
SQL 是扁平的：按 product_id / article_id + status 一次查出列表。
树是内存里拼的：children 初始化 + id 索引 + 一遍挂载。
前端是递归的：渲染当前节点，再渲染 children。

对应到 test.py：

步骤	代码	作用
准备扁平数据	`comments = [...]`	模拟 SQL 查询结果
初始化孩子数组	`comment["children"] = []`	让每个节点都能挂回复
建索引	`comment_map = {id: comment}`	O(1) 找父亲
挂载	`parent_id is None` 进根，否则进父亲的 `children`	得到树
展示	`print_tree` / `pprint`	对应前端递归渲染 / JSON 响应

这就是商品评论、文章评论、帖子回复都可以共用的实现方式。SQL 保持简单，树交给代码，系统会好懂、好测、也好改。

评论回复系统设计与实现指南