宁语之溪 - HAOVP
type: channel
link: https://nyzx.de/category/haovp/
items: HAOVP 所谓高可用，边界到底在哪里
items: 一次在线视频平台接口验收记录
items: 我如何梳理一个微服务系统
items: 我如何使用 Codex 开始开发 HAOVP
items: HAOVP 的技术选型和服务拆分
items: HAOVP 第一版功能规划
items: 我为什么开始独立做一个在线视频平台

HAOVP 所谓高可用，边界到底在哪里
type: item
date: 2026-06-13T16:46:00+08:00
description: 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 服务连续性的一部分，…

一次在线视频平台接口验收记录
type: item
date: 2026-04-25T16:42:00+08:00
description: 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，不代表业务分支一定执行正确。还要检查关键字段是否完整、远程结果是否被正确解释。第四类问题：事务内同步回写造成等待收藏链曾在主事务中同步调用其他服务更新统计，出现锁等待和慢失败。调整后，把非核心的同步回写移到事务提交之后，并以异步尽力执行的方式处理。完成核…

我如何梳理一个微服务系统
type: item
date: 2026-03-21T18:16:00+08:00
description: 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 Resu…

我如何使用 Codex 开始开发 HAOVP
type: item
date: 2025-12-27T16:39:00+08:00
description: HAOVP 的功能范围和技术方向逐渐清楚后，我开始使用 Codex 辅助项目开发。我不准备把“开发一个在线视频平台”作为一句完整指令交给 AI。这样的任务范围太大，需求、架构和验收标准也不可能一次说清。更可控的方式是由我先理解问题和做出决策，再把工作拆成可以审查和验证的小任务。目前我先用这套方式推进项目，并在每次实现、审查和联调后调整任务拆分方法。先明确责任边界在这个项目中，我和 Codex 的职责并不相同。我负责： 需求理解 技术和架构决策 任务拆解 上下文组织 代码审查 测试判断 前后端联调 最终验收 Codex 辅助： 代码实现 局部重构 测试补充 问题排查 文档整理HAOVP 是我独立完成的个人项目，责任主体是我。Codex 可以辅助很多开发工作，但不能替我决定业务规则，也不能因为代码由 AI 生成就免去审查和验证。不从“写完整系统”开始一个大任务往往包含太多隐含条件。比如“实现用户登录”至少需要继续确认：使用什么登录凭据；密码怎样保存；登录成功返回什么；身份凭证怎样刷新和失效；网关与业务服务分别校验什么；错误响应使用什么格式；哪些异常路径需要测试。因此，我会先把目标变成一组小任务：确认认证需求 -> 设计接口契约 -> 建立数据模型 -> 实现核心逻辑 -> 补充异常处理 -> 编译和测试 -> 联调每个任务尽量有清楚的输入、输出和完成条件。给 Codex 足够但不过量的上下文只描述“帮我写一个接口”，Codex 不知道项目结构和现有约定；一次塞入整个仓库，又可能让真正的问题失去重点。我会整理与当前任务直接有关的内容：模块职责和目录位置；已经确定的接口或数据模型；现有统一响应和异常处理方式；需要复用的公共能力；不允许改变的边界；编译、测试和验收条件。涉及配置时，只提供变量名称和脱敏结构，不提供真实密码、Token、地址和连接信息。先让它理解现有代码在修改已有模块前，我会先让 Codex 阅读相关文件并说明调用关系，而不是直接重写。定位入口 -> 阅读接口与实现 -> 查找数据访问和配置 -> 说明当前行为 -> 列出修改影响 -> 再开始改动如果它对现有行为的理解不准确，后面的实现很可能沿着错误方向继续。理解阶段发现的不确定项要明确标记，不能用常见框架经验代替仓库事实。一个任务只解决一个主要问题我会避免在同一个任务里同时修改认证、视频上传、评论和前端页面。改动范围越大，越难审查，也越难判断错误来自哪里。一个较小的任务可以是：为某个接口补齐参数校验；完成一个服务内的数据查询；统一一类错误响应；为现有逻辑补充单元测试；调整一个页面与接口的字段映射；更新一份与代码一致的文档。我会按实际优先级从这些小任务中逐项推进，每一项都单独记录实现和验证状态。代码生成后先看改了什么Codex 完成实现后，我不会只看最终回答，而是检查实际变更：修改了哪些文件；是否超出任务范围；是否重复实现已有工具；是否改变接口兼容性；是否增加不必要依赖；异常和边界是否处理；是否写入敏感配置；测试是否真正覆盖改动。如果出现大范围无关重构，我会要求缩小改动，而不是为了保留生成结果继续接受。编译通过只是第一道门我准备采用逐层验证方式：静态阅读 -> 编译 -> 单元或模块测试 -> 接口请求 -> 前后端联调 -> 异常与权限路径 -> 更新任务状态编译通过只能证明语法和依赖在当前条件下基本成立。接口返回成功，也不能证明数据状态、权限和副作用正确。当前项目仍处于早期开发阶段，我先把注意力放在每个小任务的编译、接口和联调结果上。让测试成为任务的一部分测试不应该等到所有功能完成后再统一补充。拆任务时，我会同时写出需要验证的正常和异常条件。例如一个创建类接口至少要考虑：合法输入能够创建；缺少必填字段会被拒绝；无权限用户不能操作；重复请求怎样处理；业务失败时是否留下不完整数据；返回结果是否与数据库状态一致。Codex 可以辅助补充测试代码和边界清单，但测试是否足够、结果是否可以接受由我判断。文档要跟随代码更新AI 辅助开发很容易快速产生代码，如果文档和任务状态没有同步，过几天就难以判断哪些是设计、哪些已经实现。我会区分：规划中的功能；正在实现的任务；已编译但未联调；已通过接口验证；仍有边界问题；已完成并验收。README 和开发文档不能只描述理想状态，需要和当前代码保持一致。当前协作方式截至 2025 年 12 月 27 日，我使用 Codex 开始开发 HAOVP 的方式可以概括为：我先确定目标和边界，把任务拆小并组织必要上下文；Codex 辅助实现和整理；我再检查改动、运行验证、处理联调问题并决定是否验收。这套方式还会随着项目推进调整。现在能确定的是，AI 辅助并没有减少开发者责任，反而要求任务描述、代码审查和验证过程更明确。

HAOVP 的技术选型和服务拆分
type: item
date: 2025-12-20T16:46:00+08:00
description: 第一版功能范围确定之后，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转码、封面提取等媒体处理方向这些技术需要分别落到具体链路中。特别是消息、缓存和多节点存储，我会把“已配置”“已实现”和“已验证”作为不同状态记录。服务边界的初步方案当前计划将后端分成统一入口和若干业务服务：统一网关 -> 认证服务 -> 用户服务 -> 内容服务 -> 评论服务 -> 推荐服务 -> 管理服务初步职责如下：认证服务：注册登录、身份凭证和认证状态；用户服务：用户资料、关系和个人设置；内容服务：视频、分类、标签、上传和播放相关数据；评论服务：评论、回复和互动状态；推荐服务：热门、相似和兴趣方向的推荐能力；管理服务：管理员、权限以及用户和内容治理入口；网关：统一路由、基础认证检查和跨域等入口能力。这套边界先作为开发起点。开发过程中如果发现调用过多、数据归属不清或职责重叠，就需要继续调整。为什么不按数据库表拆服务一个服务应该围绕业务能力，而不是一张表。按表拆分容易产生大量细粒度远程调用，也会让一个完整业务流程分散在多个服务里。我会优先考虑：哪些数据由同一业务规则管理；哪些功能经常一起变化；哪些模块需要独立扩展或隔离；服务之间是否只能通过明确接口交互；一个请求是否需要跨越过多服务。如果拆分之后每个操作都需要多个服务相互调用，说明边界可能过细。数据边界与一致性服务拆分后，数据一致性会比单体更复杂。当前不准备为所有业务强行使用同一种分布式事务方案，而是先区分场景：强一致要求高 -> 尽量在单一服务和本地事务内完成 允许短暂延迟 -> 考虑事件或异步补偿 跨服务查询 -> 通过接口或适当的数据冗余处理具体方案必须结合业务失败后果决定。不能因为技术栈中存在消息队列，就把所有跨服务操作都改成异步。统一入口和认证边界所有外部请求计划通过网关进入。网关适合做统一路由、基础认证信息检查、跨域和入口限流，但具体业务权限仍然需要由对应服务确认。客户端 -> 网关识别请求与身份 -> 路由到业务服务 -> 服务校验具体权限与状态 -> 返回统一响应认证服务负责身份凭证，用户服务负责用户业务资料，两者需要明确边界，避免认证数据和业务数据相互混杂。选型需要有退出方案某个组件如果明显增加复杂度，…

HAOVP 第一版功能规划
type: item
date: 2025-12-13T16:35:00+08:00
description: HAOVP 正式启动一周后，我需要先把“在线视频平台”这个大目标收缩成可以开发和验收的第一版。如果功能列表只按想法不断增加，项目很容易同时铺开用户、视频、互动、推荐、消息和后台管理，最后每一条链路都不完整。第一版更重要的是打通核心流程，并为后续扩展留出边界。这份规划是我目前对第一版范围的整理。接下来会根据技术验证和实际进度继续调整。第一版要回答什么问题我希望第一版至少能回答：用户能否进入系统并保持登录状态；视频内容能否被创建、保存、查看和播放；用户能否完成基本互动；管理端能否处理用户和内容；关键操作失败时是否有明确反馈；用户端、管理端和后端接口能否形成完整链路。能进入 -> 能浏览 -> 能上传 -> 能播放 -> 能互动 -> 能管理这是一条第一版目标链路，不是当前完成状态。用户与认证第一版计划包含基础用户能力：用户注册和登录；登录状态校验；基础个人资料查看和修改；用户退出；未登录、登录失效和权限不足时的统一反馈。认证部分要先保证流程清晰，不急着加入过多登录方式。Token 刷新、验证码和复杂安全策略是否进入第一版，需要在技术选型和实现时进一步确认。验收时不能只看“登录成功”，还要检查错误密码、无效账号、登录过期和越权访问等异常路径。视频内容链路视频是平台的核心对象，第一版需要优先打通：填写视频信息 -> 上传视频文件 -> 保存文件与业务记录 -> 查看视频列表和详情 -> 播放视频 -> 修改或管理内容当前规划中需要确认的内容包括：支持哪些视频格式和文件大小；视频文件、封面和业务数据怎样存储；上传失败后怎样清理不完整数据；视频处理是同步还是异步；未完成处理的视频是否允许展示；删除内容时怎样处理关联文件和互动数据。这些问题还处于需求和技术验证阶段，不能提前写成已经实现的方案。浏览、搜索和分类用户进入平台后，需要能够找到内容。第一版计划提供基础的列表、详情、分类和搜索能力。可以先从较简单的查询开始：最新内容列表；按分类浏览；根据标题或关键词搜索；视频详情与作者信息；基础分页和空结果提示。复杂筛选、全文检索和个性化排序暂时不作为第一版必须项。先确保查询口径和分页结果稳定，再考虑扩展。基础互动互动功能会影响数据关系和状态，第一版先控制范围。计划优先考虑：点赞或收藏中的基础能力；评论与回复；播放历史；基础互动数量展示。是否同时加入弹幕、关注、私信和通知，需要根据核心链路进度决定。我先把它们保留在后续清单里，不让这些扩展功能影响第一版主线。管理端如果只有用户端，没有管理能力，上传后的内容和用户状态很难处理。第一版管理端计划覆盖：管理员登录；用户列表与基础状态管理；视频列表、详情和内容状态处理；分类和标签的基础维护；评论或不合适内容的处理入口；基础操作结果反馈。复杂角色权限、操作日志和运营仪表盘可以作为扩展方向。是否进入第一版，要看基础管理链路是否已经稳定。非功能需求也要进入规划功能能用只是一个维度，第一版还需要考虑：接口返回格式是否统一；错误是否能够定位；敏感配置是否通过环境变量管理；上传文件是否校验类型和大小；关键接口是否校验身份和权限；数据库变更是否可追踪；服务和依赖是否能够在开发环境启动；日志是否避免记录密码和 Token。“高可用”在当前仍是待验证目标。第一版先建立可运行、可观测和可复测的基础，再逐步验证限流、降级和多节点等能力。暂不纳入第一版的内容为了控制范围，以下内容暂时不作为必须交付项：直播和实时连麦；成熟的机器学习推荐；大规模分布式转码集群；复杂商业化和会员体系；完整社交网络；未经验证的自动故障切换承诺。暂不纳入不代表永远不做，而是避免它们阻塞最基础的视频业务链路。怎样判断第一版完成我准备给每个功能保留可验证的完成条件：需求已明确 -> 接口或页面已实现 -> 能够编译和启动 -> 正常路径通过 -> 关键异常路径通过 -> 前后端状态一致 -> 文档和待确认项已更新Codex 可以辅助实现、重构、测试补充、排障和文档整理；我负责功能范围、技术决策、代码审查、联调和最终验收。功能被生成出来不等于完成，只有满足验收条件后才能从计划移动到已完成。当前规划结果截至 2025 年 12 月 13 日，HAOVP 第一版的重点是用户、视频、基础互动和管理端四条业务主线，并补充认证、错误处理、配置和日志等基础工程要求。接下来我会继续梳理技术选型和模块边界，再把功能拆成更小的开发任务，并在实现和联调过程中逐项更新状态。

我为什么开始独立做一个在线视频平台
type: item
date: 2025-12-06T16:22:00+08:00
description: 这个月，我正式开始做一个自己的在线视频平台项目，暂时使用 HAOVP 作为项目代号。在此之前，我接触过 Java 业务开发、接口、数据平台、服务器更新和前后端联调，也提前了解过一些微服务、容器和视频处理相关技术。但准备技术知识和真正启动项目是两件事。对我来说，项目的正式起点是 2025 年 12 月：从现在开始把目标、范围和任务明确下来，并逐步实现和验证。为什么选择在线视频平台我不想只做一个视频播放页面。在线视频平台天然会遇到多个相互关联的问题：用户怎样登录，视频怎样上传、保存和播放，评论和互动怎样组织，内容怎样管理，前台和后台怎样协作。这些问题覆盖了我想继续练习的几个方向：Java 后端和接口设计；用户端与管理端开发；文件和视频资源处理；数据库、缓存与对象存储；服务之间的边界与调用；部署、日志、监控和问题排查；功能测试与异常场景验证。选择这个题目，不是因为我已经掌握了全部技术，而是因为它足够完整，可以把零散知识放进同一个系统里逐步验证。先把目标控制在可以推进的范围“在线视频平台”很容易被写成一个过大的目标。如果一开始就把直播、复杂推荐、大规模集群和所有社交功能都放进去，项目可能长期停留在规划阶段。当前更重要的是先形成一条完整的基础链路：用户进入系统 -> 注册或登录 -> 浏览视频内容 -> 上传和管理视频 -> 播放与互动 -> 后台进行内容管理接下来我会先围绕这条基础链路逐段推进。推荐、消息、监控和多节点部署先放进后续清单，等核心流程稳定后再决定怎样展开。为什么想独立完成工作项目通常有既定的平台、业务规则和协作边界。个人项目给了我一个机会，可以从需求理解开始，自己决定功能优先级、技术方案和验收标准。独立完成并不意味着所有事情都只靠手工输入。我会使用 Codex 辅助实现、重构、测试补充、排障和文档整理，但项目的需求理解、架构和技术决策、任务拆解、代码审查、测试判断、联调和最终验收由我负责。我：目标、决策、拆解、审查与验收 Codex：实现辅助、重构、测试补充、排障与文档整理这条边界从项目开始时就需要明确。AI 可以提高实现和整理效率，却不能替我承担项目结果。启动阶段先回答几个问题在正式写大量代码之前，我需要先回答：最先服务哪类用户；第一版必须完成哪些业务链路；用户端和管理端分别承担什么职责；视频文件、封面和业务数据怎样分开保存；登录认证和权限边界如何处理；哪些功能需要拆分，哪些暂时保持简单；怎样判断一个功能真正完成；如何在不暴露敏感配置的前提下部署和记录。有些问题现在只有初步方向，还不能写成已经确定的事实。我会把不明确的部分留在待确认清单里，随着实现和验证再调整。不把“高可用”当作一句口号项目名称中包含“高可用”，我需要把这个目标拆成一组能够实际验证的问题。我目前更愿意把它拆成可以验证的问题：单个服务异常时，影响范围有多大；服务之间怎样发现和调用；请求入口怎样统一管理；数据、缓存和文件存储出现异常时怎样处理；部署后能否观察服务状态；所谓多节点方案是否真的能切换和恢复。这些问题目前都要通过后续部署和测试逐项回答。我会先建立能够运行和复现的基础环境，再记录每一项验证得到的结果。第一阶段的工作方式我准备把项目拆成可以验收的小任务，而不是一次要求 AI 生成完整系统。明确需求 -> 划分模块 -> 编写或辅助实现 -> 本地编译 -> 接口和页面联调 -> 记录问题 -> 修复并重新验证每一步都要保留判断：代码能编译不代表功能正确，接口返回成功不代表业务状态完整，页面能打开也不代表权限和异常路径已经验证。现在只是开始截至 2025 年 12 月 6 日，我能确认的是：项目正式启动，目标是独立完成一个面向学习、实验和工程实践的在线视频平台，并以完整业务链路作为持续开发方向。接下来要继续梳理第一版功能、服务边界和技术选型，再把它们拆成能够单独实现和验收的任务。我想通过这个项目得到的，不只是一个可以播放视频的网站，而是一段从需求、设计、实现到部署和验收都由自己真正走过的过程。今天先把起点记下来。