HAOVP 的名字里有“高可用”，项目设计也把高可用作为重点。项目做到这个阶段，我需要把这个词重新拆开：哪些只是技术方案，哪些已经进入仓库和部署文件，哪些经过了实际验证，以及哪些故障发生时系统仍然会不可用。如果只看组件清单，Nacos、Gateway、Sentinel、Redis Sentinel、MySQL 主从、多节点 Compose、MinIO 副本、RocketMQ、Prometheus 和 Grafana 都与高可用有关。但把这些组件放进项目，不等于整套系统已经达到生产级高可用。我用三层证据描述能力为了避免把设计目标写成结果，我把每项能力分成三层：理论设计 -> 这个方案理论上解决什么问题 仓库实现 -> 依赖、代码、配置和部署文件实际有什么 已验证结果 -> 在什么环境、什么前提和什么故障下得到过什么结果三层之间不能跳级。配置文件存在，只能证明项目有相应配置；容器启动成功，只能证明进程进入运行状态；接口能够返回预期结果，也不能自动证明节点切换和数据恢复已经完成。当前部署形态分别解决什么项目提供三种部署方式：部署形态适合场景主要边界单机 Docker Compose开发、联调和单机演示宿主机故障时整套服务可能同时不可用1Panel 单机部署单机服务器部署与维护仍然存在单主机、单磁盘和单网络入口风险Debian 多节点编排验证多实例与基础组件拓扑有编排文件不等于所有自动切换都已验证单机环境对复现和接口验收很有价值。4 月 18 日的 115 条分批接口用例就是在单机 Docker Compose 环境完成的。但这批结果不能用于证明多节点容灾，因为测试环境没有发生跨主机调度和故障切换。统一入口的边界Gateway 提供统一路由、JWT 校验、公开路径控制、CORS 和流量治理入口。客户端只需要访问统一入口，不必知道每个业务服务的位置。外部入口验收中，29 条预设用例得到预期结果，其中包括正常业务请求和预期被拒绝的认证请求。这能够说明当时的入口、路由、认证及若干核心业务链路可以连通。它不能证明：Gateway 已经部署多个实例并由外部负载入口自动切换；网关宿主机不可用时流量会迁移；所有动态路由变更都能无损生效；高并发下网关不会成为瓶颈；入口证书、DNS 和反向代理没有单点。统一入口解决访问收敛问题，但统一入口本身也需要冗余和健康检查。Nacos 的边界多节点方案为 Nacos 安排了多个节点，业务服务通过 Nacos 获取服务实例和配置。它能减少服务地址写死，也为多实例调用提供基础。但需要区分三种状态：Nacos 进程存活 < Nacos 集群能够选举并提供服务 < 业务服务能发现正确实例并完成完整调用注册中心看到服务健康，不代表数据库、Redis、对象存储和业务依赖都正常。服务可能成功注册，却因为配置错误或下游故障无法处理请求。当前文档提供了多节点配置和健康检查方法，但没有足够的故障演练记录证明：任意 Nacos 节点停止、网络分区或共享数据异常时，所有服务都能按目标恢复。业务服务多实例的边界服务多实例可以在单个实例停止时保留其他副本，但前提很多：请求入口能发现并选择健康实例；服务没有依赖本机临时状态；会话状态可以跨实例使用；数据库和缓存仍然可用；上传中的文件和异步任务能够恢复；超时、重试和幂等策略不会放大故障。一个服务启动两个容器，只能说明存在两个进程。要确认多实例容错，至少要在持续请求下停止一个实例，观察失败比例、恢复时间、连接池和日志，再验证业务副作用是否正确。目前仓库有多节点业务服务编排，但现有验收主要是接口功能和外部入口链路，不足以给出多实例切换时间或无损恢复结论。Sentinel 的边界Sentinel 可以提供限流、熔断和降级能力：限流：控制进入资源的流量 熔断：暂时停止持续失败或过慢的调用 降级：决定受保护时返回什么项目已经接入 Sentinel 相关依赖和配置方向，但规则存在不等于保护生效。每条规则都需要受控流量、慢调用、异常比例和恢复探测验证。Sentinel 也不能替代：数据库索引和查询优化；事务、幂等和消息可靠性；容器资源隔离；多节点部署；容量评估和根因修复。熔断可以限制故障扩散，却不会把失效的下游自动修好。Redis Sentinel 的边界多节点方案使用 Redis 主从和 Sentinel。Sentinel 可以监视 Redis 节点并参与主节点切换，业务服务通过 Sentinel 配置寻找当前主节点。但高可用不仅是“Sentinel 选出新主库”：主从复制可能存在延迟；故障前最后一部分写入可能尚未复制；客户端需要断开旧连接并连接新主节点；切换期间命令可能失败或重试；重试写操作需要考虑幂等；缓存数据与数据库事实仍可能不一致。Redis Sentinel 解决 Redis 服务连续性的一部分，不自动解决业务缓存一致性，也不证明验证码、令牌和权限状态在切换期间完全无损。文档提供了验证 Sentinel 主节点和停止节点后的检查步骤，但目前没有完整结果记录可以给出实际恢复时间和数据丢失范围。MySQL 主从的边界多节点拓扑中，MySQL 使用一个主库和多个从库，业务写入仍指向主库。这说明项目具备复制与副本方案。它还不等于：读请求已经稳定分流到从库；主库不可用时从库会自动提升；旧主库会被可靠隔离；应用数据库入口会自动迁移；事务在切换期间不会丢失或重复；原主库恢复后能自动安全加入。真正的故障切换需要检测、仲裁、隔离、选主、拓扑重建、入口迁移、连接恢复和数据核对。当前文档能支持主从复制和主库写入方向，不能支持未经演练的自动切换结论。MinIO 副本的边界HAOVP 的多节点 MinIO 方案是主节点承担业务写入，再把对象同步到另一个节点；还有备用实例，但不能描述为已经自动同步的原生集群。这套方案能够增加一份对象副本，却不是 MinIO 原生分布式纠删码集群。它没有自动解决：主写入点故障后的业务入口切换；同步尚未完成时的数据缺口；删除和覆盖操作的冲突；副本一致性校验；备用节点自动接管；多节点同时故障。所以更准确的说法是“主写入点加镜像副本方案”，而不是“对象存储集群已经高可用”。RocketMQ 和异步链路的边界RocketMQ 用于把部分非核心更新从同步链路中拆出去。异步消息可以降低服务间同步等待，但消息可靠性需要生产、存储、消费、重试和幂等一起成立。4 月接口验收期间，消息路由仍存在异常。内容服务通过主表降级更新，使相关接口在当前用例中得到预期结果。这条事实非常适合说明高可用的边界：业务接口在降级路径下符合预期 ≠ 消息链已经恢复正常降级保证了当前核心结果，却可能带来异步事件缺失、重复执行或统计状态来源不一致。消息路由仍需要单独修复和重放验证。监控的边界项目包含 Actuator、Prometheus 和 Grafana 相关配置。监控可以帮助观察服务状态、资源和指标，但它本身不会修复故障。一套真正有用的监控还需要：指标采集目标正确；告警阈值与业务容量匹配；告警能够送达；日志、指标和请求标识能够关联；仪表盘可以区分实例、服务和依赖；有人知道收到告警后怎样处理。配置文件和仪表盘存在，只能说明具备观测基础，不能证明告警链路和应急流程已经验证。两组验收结果能说明什么4 月 18 日有两组不同口径的结果：三批后端接口明细：29、63、23 条，合计 115 条，均符合预期；外部统一入口验收：29 条，均符合预期，其中包含预期拒绝用例。两组结果可能覆盖相同业务链路，因此不能相加成 144 个独立接口。它们能够支持的结论是：在当时的验收环境、数据和请求前提下，认证、用户、内容、评论、推荐、后台管理及统一入口的指定用例能够得到预期结果。它们不能支持：节点故障时请求无损切换；MySQL 或 Redis 自动切换结果；Nacos 网络分区恢复；MinIO 写入点自动迁移；RocketMQ 故障后消息不丢不重；高并发和长期运行稳定性；生产级恢复时间与恢复点目标。我会怎样验证下一层高可用如果继续验证，测试需要从“接口是否正确”转向“故障发生时系统怎样变化”。建立持续、可重复的业务流量 -> 记录正常基线 -> 注入单一故障 -> 观察检测、切换和降级 -> 核对请求失败与业务副作用 -> 恢复节点 -> 检查数据追平和旧节点角色故障场景至少包括：停止一个业务服务实例；停止一个 Nacos 节点；Redis 主节点不可用；MySQL 主库不可用；对象存储主写入点不可用；消息组件不可用或积压；节点间网络中断；整台宿主机停止。每次只改变一个主要变量，并记录：故障检测时间；请求失败数量和类型；恢复耗时；是否需要人工操作；是否丢失、重复或错乱数据；恢复后是否存在双主或旧连接；监控和告警是否准确。没有这类记录，就不应该给出具体恢复时间或数据零丢失承诺。我对 HAOVP 高可用的当前定义到 6 月 13 日，我更愿意这样描述 HAOVP：它是一个以学习、实验和工程实践为目标的微服务视频平台，仓库中已经包含服务治理、流量保护、缓存、数据复制、多节点编排、对象副本和监控等高可用方向；指定接口和统一入口链路已经完成一轮功能验收。它还不是经过完整故障演练和长期负载验证的生产级高可用系统。单机部署仍有宿主机单点，多节点方案中的数据库、缓存和对象存储各有切换与一致性边界，消息链也保留已知异常。“高可用”在这里不是一个已经完成的标签，而是一组可以逐项设计、实现和验证的能力。把没有验证的部分明确留下，才能知道下一步应该测试什么，也能避免组件数量掩盖真实的单点和数据风险。
4 月 18 日，我完成了一轮 HAOVP 后端接口验收。这次不是挑几个接口确认能返回数据，而是按认证与用户、内容与评论及推荐、后台管理三批执行，并把每一项的请求方法、脱敏路径、预期结果和实际状态写进 JSON 明细。最终汇总为：验收批次用例数通过失败认证与用户29290内容、评论与推荐63630后台管理23230合计1151150这里的“通过”表示实际结果符合用例预期，不等于每个请求都返回 200。例如，无验证码登录应该被拦截，普通用户访问内部审核接口也应该被拒绝；这些负向用例在得到预期拒绝结果时同样计为通过。先统一验收口径接口文档中大约有 186 条 endpoint，但其中包含重复文档项、内部接口和管理接口映射，不能直接把这个数字当作实际测试数量。我采用 JSON 明细中的独立用例作为最终口径。每条记录至少包含：{ "method": "POST", "path": "/example/resource", "status": "PASSED", "http": 200, "note": "脱敏后的测试说明" }这是结构示例，不是实际接口、账号或请求数据。三份结果文件分别有 29、63 和 23 条记录，与汇总报告完全一致。这样可以避免出现“报告写了全部通过，但明细数量对不上”的问题。为什么按模块分批执行最初如果把所有接口放进一个长脚本，某个请求超时或状态依赖出错后，后面的结果也会受到影响。为了让问题更容易定位，我按业务链路拆成三批：认证与用户 -> 注册、登录、刷新、资料、关注、通知、私信 内容、评论与推荐 -> 分类、标签、视频、互动、弹幕、统计、评论、推荐 后台管理 -> 管理员认证、用户治理、内容审核、评论管理、仪表盘分批后，每一批都可以独立准备数据、执行、清理和重测。某一模块失败时，不需要从头运行全部用例。不是只测正常请求如果只验证合法请求返回成功，很难判断认证和权限控制是否真正生效。这次验收同时包含正向和负向场景。例如：合法验证码和账号能够登录；缺少验证码的登录请求会被拦截；刷新令牌能够换取新的认证信息；用户被禁用后不能继续登录；后台重置密码后可以使用新密码登录；普通用户访问内部审核接口会被拒绝；内容置顶操作必须满足作者身份和正确的资源关系。因此，不能用“HTTP 状态不是 200”直接判断用例失败。验收器需要同时比较预期 HTTP 状态、业务状态和业务前提。一个简化判断可以写成：boolean passed = actualHttp == expectedHttp && matchesExpectedBusinessState(response) && verifySideEffect();真正的验收还要检查数据库或后续查询中的副作用，不能只看响应正文。第一类问题：运行代码和本地源码不一致排查用户和评论链时，我发现部分容器运行的还是旧构建产物，与本地源码不一致。这种问题很容易造成错觉：代码中明明已经修复，接口行为却没有变化；继续修改源码，只会让排查方向越来越偏。我先重新构建产物并更新运行环境，再核对服务实际加载的版本。以后遇到类似情况，我会先检查：当前提交版本 -> 构建产物生成时间 -> 镜像或容器中的文件 -> 服务启动日志 -> 实际接口行为只有这几层一致，才适合继续判断代码逻辑。第二类问题：公开接口被认证规则挡住用户公开资料、关注列表、分类树和标签列表等接口，本来需要允许未登录访问，但实际运行时受到认证规则限制。修复这类问题不能简单扩大白名单。每个接口都要先确认：返回内容是否确实允许公开；是否需要隐藏敏感字段；路径变量能否访问其他用户的数据；查询量是否需要限制；写操作是否仍然要求认证和权限。公开读取接口和内部管理接口必须保持边界。验收通过的是指定公开路径，不代表整个模块都应跳过认证。第三类问题：跨服务返回值判断错误内容链中曾出现视频详情和列表里的用户展示信息为空。调用用户服务本身有返回，但成功分支没有进入。根因是对包装类型状态码使用了不合适的比较方式。跨服务反序列化后得到的是对象，不能依赖对象引用相同来判断数值相等。// 容易产生问题 if (result.getCode() == expectedCode) { // ... } // 更明确的数值判断 if (Objects.equals(result.getCode(), expectedCode)) { // ... }这是简化示例，不对应实际类名和常量。这次问题提醒我：接口已经返回 200，不代表业务分支一定执行正确。还要检查关键字段是否完整、远程结果是否被正确解释。第四类问题：事务内同步回写造成等待收藏链曾在主事务中同步调用其他服务更新统计，出现锁等待和慢失败。调整后，把非核心的同步回写移到事务提交之后，并以异步尽力执行的方式处理。完成核心数据库事务 -> 事务提交 -> 异步通知统计更新 -> 失败时记录并等待后续补偿这种方式缩短了主链路，但它不是强一致方案。异步调用失败时，统计值可能暂时不一致，因此还需要日志、重试或对账机制。本轮能够确认的是接口链路已经恢复；异步调用失败后的重试、补偿和对账仍要继续验证。第五类问题：业务前提不成立导致误判评论置顶和取消置顶曾被记录为失败。重新检查后发现，这类操作要求当前用户是视频作者，并且评论确实属于传入的视频。如果测试账号身份或资源关系不满足要求，接口拒绝请求是正确行为，不应该算作系统缺陷。因此，用例不仅要保存请求参数，还要明确前置关系：测试用户身份 目标资源归属 数据当前状态 前置操作是否成功 预期允许或拒绝服务端也补充了资源归属校验，避免仅凭一个资源编号执行跨资源操作。第六类问题：数据映射和数据库约束推荐兴趣更新曾因 MyBatis 对映射集合的遍历写法不正确而失败。后台审核链还发现调用方没有传递管理员身份，以及审核记录外键指向了不合适的用户表。这两类问题分别属于：Java 数据结构与 SQL 映射不一致；服务身份与数据库关系模型不一致。修复后不能只重跑最初失败的一个接口，还要继续验证：数据是否真正写入正确表；关联字段是否指向正确主体；查询能否读回刚写入的数据；无权限主体是否仍会被拒绝；删除或状态变更是否破坏关联数据。接口返回成功只是起点，数据关系正确才是完整结果。消息组件异常时的降级边界验收期间，消息路由仍存在异常。内容服务补充了主表降级更新，使相关计数在当前请求链中能够变化。这说明本轮接口用例可以得到预期结果，但不能反推消息组件已经恢复正常。两种状态必须分开记录：业务接口结果符合预期 ≠ 所有下游组件均处于正常状态降级路径让核心结果暂时可用，也可能带来重复更新、异步事件丢失或状态来源不统一等新问题。消息链本身仍需要单独排查和验证。怎样保存可复查的结果我为每批验收保留结构化 JSON，而不是只保存终端中的“通过”字样。结构化结果便于再次统计，也能定位到具体方法、脱敏路径和备注。整理这份记录时，我只保留：模块分组；用例总数和通过数量；典型问题类型；修复与复测方法；尚未覆盖的边界。不会公开：实际服务 URL、IP 和端口；Token、密码和验证码；测试账号、用户 ID 和资源 ID；请求正文中的真实数据；数据库连接和内部路径；可以用于重放管理操作的参数。原始明细继续用于项目内部追溯，这份记录不复制全部请求。115 项通过能说明什么这轮结果可以确认：在 2026 年 4 月 18 日的单机 Docker Compose 验收环境中，三批共 115 个预设接口用例得到预期结果，认证、用户、内容、评论、推荐和后台管理的主要接口链路能够按这些用例运行。它不能证明：接口文档中的约 186 条 endpoint 都是独立且全部测试；所有参数组合和边界值都已覆盖；高并发下仍能保持相同结果；多节点故障切换已经通过；消息、缓存、数据库和对象存储始终正常；前端全部交互都已验收；系统已经达到生产环境要求。这轮验收留下的方法这次接口验收真正有价值的，不只是 115/115，而是一条可以重复执行的过程：确定独立用例口径 -> 按模块准备前置数据 -> 同时覆盖成功与拒绝场景 -> 保存结构化结果 -> 根据失败定位运行版本、权限、事务和数据关系 -> 修复后重建环境并复测 -> 区分接口通过与组件健康 -> 记录未覆盖边界接口验收不是把所有状态刷成绿色，而是让每一个“通过”都能说清测试前提、实际结果和证据范围。这样得到的结果，才适合继续用于项目复盘和下一轮验证。
HAOVP 从代码、配置和部署文件逐渐变成一套完整项目后，我开始重新梳理它的系统结构。仅有代码还不够，我需要说明这个系统为什么这样设计、各个模块如何协作、仓库材料能证明哪些能力，以及哪些结论还需要测试。面对网关、认证、用户、内容、评论、推荐和管理等多个服务，如果直接按文件目录记录，很容易变成模块清单。我需要先建立一条主线，再把需求、架构、实现、部署和验证放到合适的位置。先确定文档要回答什么我先把问题分成四层：为什么做这个系统 -> 系统需要解决哪些需求 -> 为什么选择当前架构和技术 -> 实现与验证能支持什么结论这四层对应不同证据：背景说明需要可靠的公开资料支持；需求分析需要来自实际功能范围；架构与实现需要由仓库、配置和代码支持；测试结论需要可复现的测试记录支持。如果把这几类内容混在一起，设计目标很容易被写成已经实现，配置文件也容易被当成验证结果。从文档目录建立主线我先搭出六个主要部分：项目背景与目标 相关技术与选择依据 系统需求与总体设计 核心模块实现 高可用方向与边界 测试方法与结果这个顺序不是简单按开发时间排列，而是一条论证链：先说明问题，再介绍解决问题需要的技术，然后给出系统设计、实现方式和验证方法。每一部分都要能回答一个具体问题。例如：“微服务模块划分”解释服务边界；“模块间通信与协作”解释请求怎样跨服务流动；“数据库设计”解释数据归属和关系；“服务注册与发现”解释实例怎样被找到；“流量控制与熔断降级”解释异常怎样被限制；“缓存策略与数据一致性”解释性能和状态之间的取舍；“测试环境与方法”解释结论怎样得到。如果某一节只能堆技术名词，却无法说明它在系统中的作用，就需要重新调整。把仓库结构翻译成系统结构仓库中的模块结构更接近开发视角：统一网关 认证服务 用户服务 内容服务 评论服务 推荐服务 管理服务 公共模块 前端用户端与管理端 基础设施与部署文件系统文档需要把这些模块放进更大的关系中：客户端 -> 网关与访问控制 -> 业务服务 -> 数据库、缓存、对象存储和消息组件 -> 监控与部署这样写可以避免逐个类、逐个接口介绍。文档关注的是服务职责、调用关系和关键实现，代码细节只在能说明设计时出现。先画边界，再写模块微服务系统最容易出现的问题，是每个模块都写了很多功能，却没有说明边界为什么这样划分。我会先为每个服务写一张简表：服务负责的数据和行为需要调用谁不负责什么认证服务登录、令牌与认证状态用户服务、Redis用户业务资料内容服务视频、分类、标签与上传链路对象存储等组件评论树和推荐排序评论服务评论、回复与互动状态内容或用户相关接口视频文件处理推荐服务行为、兴趣和候选结果内容服务视频元数据事实来源表中的内容是对 HAOVP 服务职责的概括，不包含内部地址和真实配置。当“负责什么”和“不负责什么”都能写清楚时，服务拆分才不只是项目中存在多个目录。技术章节不能脱离使用场景系统中会出现 Spring Cloud、Nacos、Gateway、Sentinel、MySQL、Redis、MinIO、RocketMQ 和 FFmpeg 等内容。如果按百科形式介绍，每一节都可能正确，但与项目关系不大。我更希望按“问题—选择—边界”来写：服务地址会变化 -> 使用 Nacos 做注册发现 -> 实例健康不等于业务链路健康 外部请求需要统一入口 -> 使用 Gateway 做路由和通用校验 -> 业务权限仍由业务服务判断 视频文件不适合放进关系数据库 -> 使用对象存储保存文件 -> 元数据和业务状态仍由数据库管理这样既能说明为什么使用某项技术，也能保留它解决不了的问题。设计、代码和部署要相互核对架构图、部署图和时序图不能只追求完整。每画出一个节点或一条调用线，我都需要回到项目中找依据。我会按以下顺序核对：文档中的技术或组件 -> README 是否列出 -> 依赖是否存在 -> 配置是否存在 -> 代码是否真正调用 -> 部署文件是否包含 -> 是否有运行或测试记录不同层级支持的写法不同：README 中的规划可以写“项目计划采用”；依赖和配置存在可以写“项目已接入相关组件”；代码路径存在可以说明具体实现；部署成功和测试通过必须有单独记录。例如，技术分析中可以讨论某种分布式事务或数据库集群方案，但如果仓库中没有对应运行时依赖和验证记录，就不能在实现说明中直接写成已经完成。代码示例只保留关键部分项目文档不需要粘贴完整控制器或服务实现。过长代码会遮住真正想说明的逻辑，也可能带出内部配置。我会把代码示例缩小到一个判断点：public Result<?> handle(Request request) { validate(request); Object result = service.execute(request); return Result.success(result); }这是结构示例。真正整理代码片段时，需要选择能够说明认证、缓存、推荐或容错逻辑的片段，并去掉无关代码、真实地址、密钥和测试数据。每段代码前后还要回答：这段代码解决什么问题；为什么放在这一层；异常时怎样处理；它与其他服务怎样协作；当前实现还有什么限制。没有这些解释，代码片段本身不能证明设计合理。图表要与文字互相补充微服务系统中，很多关系只靠文字很难讲清。我准备使用不同图表表达不同问题：架构图：系统由哪些层和组件组成；模块图：服务职责与依赖关系；时序图：登录、上传或评论等请求怎样流动；数据库关系图：核心实体怎样关联；部署图：服务实例和基础组件放在哪里；测试表：输入、步骤、预期和实际结果。一张图只解决一个主要问题。把所有服务、端口、数据库表和调用关系挤在一张图里，信息很多，却不一定更清楚。图中的名称还要和正文、代码保持一致。如果正文写“内容服务”，图里却使用另一个历史名称，读者会误以为是两个模块。高可用章节先写能力边界“高可用”不能只靠多节点、Docker Compose 或几个中间件支撑。我把高可用拆成几个可以单独检查的方面：服务发现与多实例 统一入口与流量控制 超时、熔断和降级 数据复制与故障切换 缓存与数据一致性 对象存储副本 监控、告警与恢复每个方面都要区分：理论上解决什么问题；HAOVP 当前采用什么方案；配置和代码完成到什么程度；还需要怎样测试；哪些故障仍可能让系统不可用。例如，单机 Compose 可以统一编排环境，但宿主机故障时所有容器仍可能一起不可用；MySQL 主从提供副本，但没有选主和流量迁移就不等于自动故障切换；对象副本同步也不等于原生分布式存储。把这些边界写出来，比笼统地说“系统具备高可用”更准确。测试部分先写方法，不提前写结果当前已经规划了功能、性能、压力和容错测试，但 3 月 21 日这一天，我只能先确定测试方法和记录格式，不能用尚未完成的测试填结论。一个测试条目至少包含：测试目标 前置条件 请求或操作步骤 预期结果 实际结果 日志或数据证据 是否通过 异常与备注功能测试要覆盖登录、视频、评论、推荐和管理等主要链路；容错测试则要明确停止哪个实例、怎样观察故障、如何判断恢复。性能测试同样不能只写一个平均响应时间。还需要记录并发模型、请求分布、测试时长、数据规模、环境资源和高分位耗时。环境和方法不完整，单个数字没有足够意义。用事实强度约束文档用词整理过程中，我给常见写法设了一条强度顺序：计划采用 < 已完成设计 < 已有配置或代码 < 已部署运行 < 已经过指定场景验证只有证据到达相应层级，才能使用更强的表达。这条规则也适用于个人职责。HAOVP 是我的个人项目，我负责需求理解、架构和技术决策、任务拆解、代码审查、测试判断、联调与验收；Codex 辅助代码实现、局部重构、测试补充、问题排查和文档整理。工具辅助不能被写成工具独立完成，也不能因为项目由我独立完成，就扩大成所有技术方案都已经达到生产级水平。每部分完成后做一次反向检查一部分写完后，我不会只检查错别字，而是从结论往回找证据：这一节得出了什么结论？ -> 结论依赖哪些事实？ -> 事实来自代码、配置、文档还是测试？ -> 来源时间是否早于当前记录时间？ -> 是否把设计和实现混在了一起？ -> 是否泄露了账号、地址或个人信息？如果某句话找不到来源，就把它改成设计目标、待验证问题，或者直接删除。这次梳理给我的结果这次系统梳理让我从“功能能不能运行”转向“系统能不能被解释”。服务为什么拆分、数据为什么放在这里、故障为什么不会或仍然会扩散，都需要明确答案。目前项目文档的主线已经建立，接下来要继续核对图表、实现片段和测试方法，把设计、代码、部署与验证分别放在正确位置。文档可以总结项目，但不能替项目补出不存在的实现；只有能从材料和测试中追溯的内容，才适合作为结论写下来。
微服务拆分时，服务边界应该如何确定
微服务拆分最容易做的事情，是按照页面菜单或数据库表建立多个服务；最难的事情，是判断哪些业务应该放在一起，哪些能力值得独立变化和部署。在 HAOVP 的设计中，我把认证、用户、内容、评论、推荐和管理等能力分开。这个方案适合当前项目的学习和实验目标，但并不意味着所有在线视频平台都应该采用相同拆法。先看业务能力，不先看表数据库表是实现结构，服务边界应该优先围绕业务能力。例如，“视频内容”不仅是一张视频表，还可能包括：视频基础信息；分类和标签；上传与文件状态；内容审核状态；播放和收藏相关入口；与对象存储和媒体处理的协作。如果按表拆服务，一个完整的视频操作可能需要跨越多个服务，调用链会变得很长。业务目标 -> 核心规则 -> 数据归属 -> 对外能力 -> 服务边界哪些内容应该放在一起我会重点看几个判断条件：是否围绕同一个业务对象；是否由同一组规则约束；是否经常一起修改；是否需要在一个本地事务内完成；是否由同一类角色负责；是否具有相近的性能和扩展需求。例如，用户身份凭证与用户业务资料有关联，但变化原因不同。认证更关注登录、凭证和失效控制；用户资料更关注昵称、头像、关注关系和设置。把它们分开，可以让认证边界更清楚，但也会增加注册初始化和用户状态同步的协作成本。数据归属必须明确服务拆分后，每类核心数据需要有明确的负责方。认证服务 -> 登录凭证与认证状态 用户服务 -> 用户资料与用户关系 内容服务 -> 视频、分类、标签与内容状态 评论服务 -> 评论、回复与评论互动 管理服务 -> 管理员、角色和治理入口这是一份脱敏的项目设计示例。真正重要的不是名称，而是避免多个服务直接修改同一份核心数据。如果一个字段的归属不清，就容易出现：多个服务都能修改；状态变化没有唯一入口；一个服务绕过另一个服务的规则；出现差异时不知道以谁为准。跨服务调用不能无限增长拆分后，一个业务流程可能需要多个服务协作。调用不是越多越“微服务化”。我会画出关键请求链路：客户端 -> 网关 -> 内容服务 -> 用户服务 -> 返回结果然后继续检查：同步调用是否真的必要；是否可以由调用方只保存业务标识；某些展示信息能否异步更新或适当冗余；下游失败时上游怎样处理；是否形成循环依赖；一个请求跨越了多少边界。如果两个服务总是同时调用、同时发布和同时修改，拆分可能没有带来实际收益。事务边界会影响服务边界强一致业务如果被拆到多个服务，处理难度会明显增加。例如一个操作需要同时写入两类数据，可以先问：它们是否属于同一业务聚合；是否必须同时成功或失败；能否调整数据归属，让操作在单一服务完成；是否允许短暂不一致；失败后是否有明确补偿方式。必须立即一致 -> 优先收敛到单一服务与本地事务 允许最终一致 -> 考虑事件通知和补偿 只是查询展示 -> 接口查询或适当冗余不能因为已经选择消息队列，就把所有跨服务事务都交给异步消息。独立扩展也是拆分依据视频上传和媒体处理可能比普通查询消耗更多资源；推荐计算和评论写入也有不同特征。如果某类能力需要独立扩容、限流或故障隔离，它更适合拥有清楚边界。但“未来可能扩展”不能成为无限拆分的理由。第一版数据量和调用关系还不明确时，可以先保持边界清晰、实现简单，再根据实际压力调整。管理端不是所有业务的复制品管理服务容易被写成一个可以直接操作所有表的“大后台”。这样虽然开发方便，却会绕过各业务服务自己的规则。更合适的方向是：管理服务负责管理员认证、角色和治理入口；具体业务状态仍由对应业务服务处理；管理端通过清晰接口执行审核、禁用或删除；操作日志记录谁在什么时间执行了什么动作。管理权限更高，但不应该意味着可以跳过业务约束。服务边界需要通过代码验证画完架构图后，我会在开发中继续观察：公共模块是否越来越大；DTO 是否在多个服务间反复复制；服务间调用是否过于频繁；数据库是否仍被跨服务访问；一个需求是否总要同时改多个服务；测试时是否难以独立启动模块。这些现象比图上的方框更能说明边界是否合理。当前使用的检查表维度需要回答的问题业务是否围绕完整的业务能力数据核心数据由谁负责事务哪些操作必须在同一事务内调用是否出现过长或循环调用变化是否能够相对独立演进部署是否值得独立启动和扩展故障下游异常时影响范围是什么服务边界不是一次确定后永远不变。我会先按当前业务和数据归属建立边界，再在实现、联调和部署过程中根据实际调用关系调整。微服务拆分时，服务边界应该围绕业务能力、数据所有权、事务范围和独立变化来确定。拆得过粗会失去隔离意义，拆得过细会把复杂度转移到网络调用和一致性处理中。适合当前系统的边界，才是有价值的边界。
HAOVP 的功能范围和技术方向逐渐清楚后，我开始使用 Codex 辅助项目开发。我不准备把“开发一个在线视频平台”作为一句完整指令交给 AI。这样的任务范围太大，需求、架构和验收标准也不可能一次说清。更可控的方式是由我先理解问题和做出决策，再把工作拆成可以审查和验证的小任务。目前我先用这套方式推进项目，并在每次实现、审查和联调后调整任务拆分方法。先明确责任边界在这个项目中，我和 Codex 的职责并不相同。我负责： 需求理解 技术和架构决策 任务拆解 上下文组织 代码审查 测试判断 前后端联调 最终验收 Codex 辅助： 代码实现 局部重构 测试补充 问题排查 文档整理HAOVP 是我独立完成的个人项目，责任主体是我。Codex 可以辅助很多开发工作，但不能替我决定业务规则，也不能因为代码由 AI 生成就免去审查和验证。不从“写完整系统”开始一个大任务往往包含太多隐含条件。比如“实现用户登录”至少需要继续确认：使用什么登录凭据；密码怎样保存；登录成功返回什么；身份凭证怎样刷新和失效；网关与业务服务分别校验什么；错误响应使用什么格式；哪些异常路径需要测试。因此，我会先把目标变成一组小任务：确认认证需求 -> 设计接口契约 -> 建立数据模型 -> 实现核心逻辑 -> 补充异常处理 -> 编译和测试 -> 联调每个任务尽量有清楚的输入、输出和完成条件。给 Codex 足够但不过量的上下文只描述“帮我写一个接口”，Codex 不知道项目结构和现有约定；一次塞入整个仓库，又可能让真正的问题失去重点。我会整理与当前任务直接有关的内容：模块职责和目录位置；已经确定的接口或数据模型；现有统一响应和异常处理方式；需要复用的公共能力；不允许改变的边界；编译、测试和验收条件。涉及配置时，只提供变量名称和脱敏结构，不提供真实密码、Token、地址和连接信息。先让它理解现有代码在修改已有模块前，我会先让 Codex 阅读相关文件并说明调用关系，而不是直接重写。定位入口 -> 阅读接口与实现 -> 查找数据访问和配置 -> 说明当前行为 -> 列出修改影响 -> 再开始改动如果它对现有行为的理解不准确，后面的实现很可能沿着错误方向继续。理解阶段发现的不确定项要明确标记，不能用常见框架经验代替仓库事实。一个任务只解决一个主要问题我会避免在同一个任务里同时修改认证、视频上传、评论和前端页面。改动范围越大，越难审查，也越难判断错误来自哪里。一个较小的任务可以是：为某个接口补齐参数校验；完成一个服务内的数据查询；统一一类错误响应；为现有逻辑补充单元测试；调整一个页面与接口的字段映射；更新一份与代码一致的文档。我会按实际优先级从这些小任务中逐项推进，每一项都单独记录实现和验证状态。代码生成后先看改了什么Codex 完成实现后，我不会只看最终回答，而是检查实际变更：修改了哪些文件；是否超出任务范围；是否重复实现已有工具；是否改变接口兼容性；是否增加不必要依赖；异常和边界是否处理；是否写入敏感配置；测试是否真正覆盖改动。如果出现大范围无关重构，我会要求缩小改动，而不是为了保留生成结果继续接受。编译通过只是第一道门我准备采用逐层验证方式：静态阅读 -> 编译 -> 单元或模块测试 -> 接口请求 -> 前后端联调 -> 异常与权限路径 -> 更新任务状态编译通过只能证明语法和依赖在当前条件下基本成立。接口返回成功，也不能证明数据状态、权限和副作用正确。当前项目仍处于早期开发阶段，我先把注意力放在每个小任务的编译、接口和联调结果上。让测试成为任务的一部分测试不应该等到所有功能完成后再统一补充。拆任务时，我会同时写出需要验证的正常和异常条件。例如一个创建类接口至少要考虑：合法输入能够创建；缺少必填字段会被拒绝；无权限用户不能操作；重复请求怎样处理；业务失败时是否留下不完整数据；返回结果是否与数据库状态一致。Codex 可以辅助补充测试代码和边界清单，但测试是否足够、结果是否可以接受由我判断。文档要跟随代码更新AI 辅助开发很容易快速产生代码，如果文档和任务状态没有同步，过几天就难以判断哪些是设计、哪些已经实现。我会区分：规划中的功能；正在实现的任务；已编译但未联调；已通过接口验证；仍有边界问题；已完成并验收。README 和开发文档不能只描述理想状态，需要和当前代码保持一致。当前协作方式截至 2025 年 12 月 27 日，我使用 Codex 开始开发 HAOVP 的方式可以概括为：我先确定目标和边界，把任务拆小并组织必要上下文；Codex 辅助实现和整理；我再检查改动、运行验证、处理联调问题并决定是否验收。这套方式还会随着项目推进调整。现在能确定的是，AI 辅助并没有减少开发者责任，反而要求任务描述、代码审查和验证过程更明确。
第一版功能范围确定之后，HAOVP 接下来需要回答两个问题：采用什么技术栈，以及业务应该怎样划分边界。技术越多并不代表系统越合理。个人项目更容易出现“为了使用组件而使用组件”的情况，所以每一项选型都需要对应具体问题；服务拆分也不能只按功能名称切开，还要考虑数据归属、调用关系和独立变化的可能性。目前先确定技术选型和服务边界，接下来再通过编码、启动、联调和部署逐项验证这些选择是否合适。为什么考虑微服务如果只追求尽快做出页面，单体应用会更直接。但 HAOVP 的目标不仅是完成基础视频业务，也希望练习服务治理、独立部署、故障隔离和多模块协作。视频平台中的业务资源差异较大：登录认证关注身份和安全；视频上传与处理消耗文件、CPU 和存储资源；评论互动更偏向高频写入；推荐与行为数据需要独立演进；管理端关注审核、权限和运营管理。这些模块未来可能以不同节奏变化，因此我计划采用微服务方式拆分。但微服务会增加配置、调用、数据一致性、部署和排障成本，这些成本也要进入项目范围。后端基础技术后端计划使用 Java 17 和 Spring Boot 3，主要原因是：Java 是我已有工作经验的主要语言；Spring Boot 适合快速建立统一的 Web、配置和数据访问基础；Java 17 是长期支持版本，可以使用较新的生态；后续接入 Spring Cloud 时版本关系相对清晰。微服务治理计划围绕 Spring Cloud 和 Spring Cloud Alibaba 展开，重点考虑：Gateway 作为统一入口；Nacos 提供服务注册发现和配置管理；OpenFeign 简化服务间 HTTP 调用；Sentinel 用于限流、熔断和降级方向的验证。这些目前是选型和设计目标。组件加入依赖不等于能力已经生效，后续还需要通过配置、部署和故障场景验证。用户端和管理端前端计划使用 Vue 3 与 TypeScript，分别建设用户端和管理端。用户端更关注：内容浏览和播放；上传与互动；个人资料和使用状态；移动端适配。管理端更关注：用户和内容管理；审核与状态处理；分类、标签和评论治理；权限与运营信息。两个前端可以共享后端能力和接口规范，但页面组件、交互方式和权限入口不同。现阶段先确定分端方向，再按核心流程逐步推进页面和管理功能。数据与基础设施不同数据适合不同的存储方式：数据类型当前选型方向主要用途业务数据MySQL用户、视频、评论和管理数据缓存与短期状态Redis缓存、验证码或状态控制方向视频与图片MinIO视频文件、封面和头像等对象异步任务RocketMQ事件通知和异步处理方向视频处理FFmpeg转码、封面提取等媒体处理方向这些技术需要分别落到具体链路中。特别是消息、缓存和多节点存储，我会把“已配置”“已实现”和“已验证”作为不同状态记录。服务边界的初步方案当前计划将后端分成统一入口和若干业务服务：统一网关 -> 认证服务 -> 用户服务 -> 内容服务 -> 评论服务 -> 推荐服务 -> 管理服务初步职责如下：认证服务：注册登录、身份凭证和认证状态；用户服务：用户资料、关系和个人设置；内容服务：视频、分类、标签、上传和播放相关数据；评论服务：评论、回复和互动状态；推荐服务：热门、相似和兴趣方向的推荐能力；管理服务：管理员、权限以及用户和内容治理入口；网关：统一路由、基础认证检查和跨域等入口能力。这套边界先作为开发起点。开发过程中如果发现调用过多、数据归属不清或职责重叠，就需要继续调整。为什么不按数据库表拆服务一个服务应该围绕业务能力，而不是一张表。按表拆分容易产生大量细粒度远程调用，也会让一个完整业务流程分散在多个服务里。我会优先考虑：哪些数据由同一业务规则管理；哪些功能经常一起变化；哪些模块需要独立扩展或隔离；服务之间是否只能通过明确接口交互；一个请求是否需要跨越过多服务。如果拆分之后每个操作都需要多个服务相互调用，说明边界可能过细。数据边界与一致性服务拆分后，数据一致性会比单体更复杂。当前不准备为所有业务强行使用同一种分布式事务方案，而是先区分场景：强一致要求高 -> 尽量在单一服务和本地事务内完成 允许短暂延迟 -> 考虑事件或异步补偿 跨服务查询 -> 通过接口或适当的数据冗余处理具体方案必须结合业务失败后果决定。不能因为技术栈中存在消息队列，就把所有跨服务操作都改成异步。统一入口和认证边界所有外部请求计划通过网关进入。网关适合做统一路由、基础认证信息检查、跨域和入口限流，但具体业务权限仍然需要由对应服务确认。客户端 -> 网关识别请求与身份 -> 路由到业务服务 -> 服务校验具体权限与状态 -> 返回统一响应认证服务负责身份凭证，用户服务负责用户业务资料，两者需要明确边界，避免认证数据和业务数据相互混杂。选型需要有退出方案某个组件如果明显增加复杂度，却没有解决当前问题，就应该允许暂缓或替换。例如：第一版消息量很小时，异步链路先保持简单；推荐服务先使用可解释的基础策略，等行为数据和基础链路稳定后再继续扩展；多节点部署未验证前，先保证单机环境可启动和复现；限流、熔断和降级必须经过测试，不能只看配置文件存在。个人项目的目标是理解和验证技术，而不是把组件名称堆进 README。当前设计结论截至 2025 年 12 月 20 日，HAOVP 计划采用 Java 17、Spring Boot 3、Spring Cloud、Vue 3 等作为主要技术基础，并以网关、认证、用户、内容、评论、推荐和管理等能力划分服务边界。下一步需要把设计继续落到模块结构、接口契约、数据归属和可运行的开发环境中，再通过编译、联调和部署检查这些选择是否真正合适。
HAOVP 正式启动一周后，我需要先把“在线视频平台”这个大目标收缩成可以开发和验收的第一版。如果功能列表只按想法不断增加，项目很容易同时铺开用户、视频、互动、推荐、消息和后台管理，最后每一条链路都不完整。第一版更重要的是打通核心流程，并为后续扩展留出边界。这份规划是我目前对第一版范围的整理。接下来会根据技术验证和实际进度继续调整。第一版要回答什么问题我希望第一版至少能回答：用户能否进入系统并保持登录状态；视频内容能否被创建、保存、查看和播放；用户能否完成基本互动；管理端能否处理用户和内容；关键操作失败时是否有明确反馈；用户端、管理端和后端接口能否形成完整链路。能进入 -> 能浏览 -> 能上传 -> 能播放 -> 能互动 -> 能管理这是一条第一版目标链路，不是当前完成状态。用户与认证第一版计划包含基础用户能力：用户注册和登录；登录状态校验；基础个人资料查看和修改；用户退出；未登录、登录失效和权限不足时的统一反馈。认证部分要先保证流程清晰，不急着加入过多登录方式。Token 刷新、验证码和复杂安全策略是否进入第一版，需要在技术选型和实现时进一步确认。验收时不能只看“登录成功”，还要检查错误密码、无效账号、登录过期和越权访问等异常路径。视频内容链路视频是平台的核心对象，第一版需要优先打通：填写视频信息 -> 上传视频文件 -> 保存文件与业务记录 -> 查看视频列表和详情 -> 播放视频 -> 修改或管理内容当前规划中需要确认的内容包括：支持哪些视频格式和文件大小；视频文件、封面和业务数据怎样存储；上传失败后怎样清理不完整数据；视频处理是同步还是异步；未完成处理的视频是否允许展示；删除内容时怎样处理关联文件和互动数据。这些问题还处于需求和技术验证阶段，不能提前写成已经实现的方案。浏览、搜索和分类用户进入平台后，需要能够找到内容。第一版计划提供基础的列表、详情、分类和搜索能力。可以先从较简单的查询开始：最新内容列表；按分类浏览；根据标题或关键词搜索；视频详情与作者信息；基础分页和空结果提示。复杂筛选、全文检索和个性化排序暂时不作为第一版必须项。先确保查询口径和分页结果稳定，再考虑扩展。基础互动互动功能会影响数据关系和状态，第一版先控制范围。计划优先考虑：点赞或收藏中的基础能力；评论与回复；播放历史；基础互动数量展示。是否同时加入弹幕、关注、私信和通知，需要根据核心链路进度决定。我先把它们保留在后续清单里，不让这些扩展功能影响第一版主线。管理端如果只有用户端，没有管理能力，上传后的内容和用户状态很难处理。第一版管理端计划覆盖：管理员登录；用户列表与基础状态管理；视频列表、详情和内容状态处理；分类和标签的基础维护；评论或不合适内容的处理入口；基础操作结果反馈。复杂角色权限、操作日志和运营仪表盘可以作为扩展方向。是否进入第一版，要看基础管理链路是否已经稳定。非功能需求也要进入规划功能能用只是一个维度，第一版还需要考虑：接口返回格式是否统一；错误是否能够定位；敏感配置是否通过环境变量管理；上传文件是否校验类型和大小；关键接口是否校验身份和权限；数据库变更是否可追踪；服务和依赖是否能够在开发环境启动；日志是否避免记录密码和 Token。“高可用”在当前仍是待验证目标。第一版先建立可运行、可观测和可复测的基础，再逐步验证限流、降级和多节点等能力。暂不纳入第一版的内容为了控制范围，以下内容暂时不作为必须交付项：直播和实时连麦；成熟的机器学习推荐；大规模分布式转码集群；复杂商业化和会员体系；完整社交网络；未经验证的自动故障切换承诺。暂不纳入不代表永远不做，而是避免它们阻塞最基础的视频业务链路。怎样判断第一版完成我准备给每个功能保留可验证的完成条件：需求已明确 -> 接口或页面已实现 -> 能够编译和启动 -> 正常路径通过 -> 关键异常路径通过 -> 前后端状态一致 -> 文档和待确认项已更新Codex 可以辅助实现、重构、测试补充、排障和文档整理；我负责功能范围、技术决策、代码审查、联调和最终验收。功能被生成出来不等于完成，只有满足验收条件后才能从计划移动到已完成。当前规划结果截至 2025 年 12 月 13 日，HAOVP 第一版的重点是用户、视频、基础互动和管理端四条业务主线，并补充认证、错误处理、配置和日志等基础工程要求。接下来我会继续梳理技术选型和模块边界，再把功能拆成更小的开发任务，并在实现和联调过程中逐项更新状态。
我为什么开始独立做一个在线视频平台
这个月，我正式开始做一个自己的在线视频平台项目，暂时使用 HAOVP 作为项目代号。在此之前，我接触过 Java 业务开发、接口、数据平台、服务器更新和前后端联调，也提前了解过一些微服务、容器和视频处理相关技术。但准备技术知识和真正启动项目是两件事。对我来说，项目的正式起点是 2025 年 12 月：从现在开始把目标、范围和任务明确下来，并逐步实现和验证。为什么选择在线视频平台我不想只做一个视频播放页面。在线视频平台天然会遇到多个相互关联的问题：用户怎样登录，视频怎样上传、保存和播放，评论和互动怎样组织，内容怎样管理，前台和后台怎样协作。这些问题覆盖了我想继续练习的几个方向：Java 后端和接口设计；用户端与管理端开发；文件和视频资源处理；数据库、缓存与对象存储；服务之间的边界与调用；部署、日志、监控和问题排查；功能测试与异常场景验证。选择这个题目，不是因为我已经掌握了全部技术，而是因为它足够完整，可以把零散知识放进同一个系统里逐步验证。先把目标控制在可以推进的范围“在线视频平台”很容易被写成一个过大的目标。如果一开始就把直播、复杂推荐、大规模集群和所有社交功能都放进去，项目可能长期停留在规划阶段。当前更重要的是先形成一条完整的基础链路：用户进入系统 -> 注册或登录 -> 浏览视频内容 -> 上传和管理视频 -> 播放与互动 -> 后台进行内容管理接下来我会先围绕这条基础链路逐段推进。推荐、消息、监控和多节点部署先放进后续清单，等核心流程稳定后再决定怎样展开。为什么想独立完成工作项目通常有既定的平台、业务规则和协作边界。个人项目给了我一个机会，可以从需求理解开始，自己决定功能优先级、技术方案和验收标准。独立完成并不意味着所有事情都只靠手工输入。我会使用 Codex 辅助实现、重构、测试补充、排障和文档整理，但项目的需求理解、架构和技术决策、任务拆解、代码审查、测试判断、联调和最终验收由我负责。我：目标、决策、拆解、审查与验收 Codex：实现辅助、重构、测试补充、排障与文档整理这条边界从项目开始时就需要明确。AI 可以提高实现和整理效率，却不能替我承担项目结果。启动阶段先回答几个问题在正式写大量代码之前，我需要先回答：最先服务哪类用户；第一版必须完成哪些业务链路；用户端和管理端分别承担什么职责；视频文件、封面和业务数据怎样分开保存；登录认证和权限边界如何处理；哪些功能需要拆分，哪些暂时保持简单；怎样判断一个功能真正完成；如何在不暴露敏感配置的前提下部署和记录。有些问题现在只有初步方向，还不能写成已经确定的事实。我会把不明确的部分留在待确认清单里，随着实现和验证再调整。不把“高可用”当作一句口号项目名称中包含“高可用”，我需要把这个目标拆成一组能够实际验证的问题。我目前更愿意把它拆成可以验证的问题：单个服务异常时，影响范围有多大；服务之间怎样发现和调用；请求入口怎样统一管理；数据、缓存和文件存储出现异常时怎样处理；部署后能否观察服务状态；所谓多节点方案是否真的能切换和恢复。这些问题目前都要通过后续部署和测试逐项回答。我会先建立能够运行和复现的基础环境，再记录每一项验证得到的结果。第一阶段的工作方式我准备把项目拆成可以验收的小任务，而不是一次要求 AI 生成完整系统。明确需求 -> 划分模块 -> 编写或辅助实现 -> 本地编译 -> 接口和页面联调 -> 记录问题 -> 修复并重新验证每一步都要保留判断：代码能编译不代表功能正确，接口返回成功不代表业务状态完整，页面能打开也不代表权限和异常路径已经验证。现在只是开始截至 2025 年 12 月 6 日，我能确认的是：项目正式启动，目标是独立完成一个面向学习、实验和工程实践的在线视频平台，并以完整业务链路作为持续开发方向。接下来要继续梳理第一版功能、服务边界和技术选型，再把它们拆成能够单独实现和验收的任务。我想通过这个项目得到的，不只是一个可以播放视频的网站，而是一段从需求、设计、实现到部署和验收都由自己真正走过的过程。今天先把起点记下来。