做产品发布的人都会遇到同一个现象新品上线当天流量、注册、媒体曝光全部冲高随后几天快速回落最后变成一条几乎不产生新发现的冷数据。创始人需要的并不是一次性曝光而是在发布日之后仍然有稳定渠道被潜在用户、合作伙伴和早期投资人发现。LaunchUp 正是围绕这个命题出现的社区项目它不只在发布当天把产品递出去而是把创始人档案、产品更新、话题标签、持续动态组织成一套长期可检索、可订阅、可推荐的信息系统。从工程角度拆开看这个需求会直接决定数据模型、Feed 结构、搜索方案和内容分发机制。这篇文章从一个可实现的社区系统出发梳理这类平台的设计思路、技术栈选择、数据表结构、核心接口实现以及上线后最常遇到的问题和排查方法。1. 先理解“发布日之后如何被持续发现”这个命题1.1 发布日流量为什么留不住大多数产品发布平台的流量曲线是典型的“脉冲型”。发布当天产品页通过首页推荐、社交媒体转发、邮件外推获得一个流量高峰之后因为缺少新的内容更新和新的互动信号页面权重快速下降几乎不再进入普通用户的视野。这里的问题不是发布渠道不够多而是信息架构没有为“持续发现”做设计。一次发布会带来三个结果产品页面、一批截图、一堆外部链接。这三点在发布结束后都是静态信息。静态信息只能被“检索到一次”很难被“反复遇见”。真正的长效发现依赖三个能力创始人或团队有可识别的身份档案和主题领域。产品持续产生新的更新、里程碑、案例或社区讨论。平台有机制把上述信息主动推给对它感兴趣的人比如关注流、订阅邮件、标签页和搜索。这三点缺任何一个发布日之后都会失去发现入口。1.2 从产品口号反推工程需求把“帮助创始人在发布日之后持续被发现”当作一个技术需求来拆解会得到一组非常具体的功能关键词创始人档案页访问者可以了解这个人在做什么、在哪条赛道、有什么历史背景。项目页和更新流展示产品从发布到后期迭代的完整时间线。标签与话题把分散的创始人按 AI、SaaS、开发者工具、消费品牌等赛道聚合成垂直列表。关注与订阅用户可以选择关注某个项目或某个创始人之后在 Feed 里看到持续动态。全站搜索让新用户通过关键词找到已经发布 30 天、90 天甚至更久的项目。周期性触达每周摘要邮件、热门项目推送把已经“沉默”的项目重新带回用户视野。这些功能每一条都不复杂但组合起来就构成了一个可持续运营的信息闭环。工程上最难的部分不是单个功能而是这些功能共享同一套数据模型并且要在一套 Feed 和搜索体系里保持一致。1.3 平台的信息闭环LaunchUp 这类社区的信息循环可以抽象成五步创始人创建档案并提交项目。项目进入标签池被初始分类收录。项目发布后产生首批访问访问者可以选择关注。创始人持续发布更新关注者在 Feed 中收到新的动态。每周摘要或搜索再次推荐项目让错过首发的人重新发现它。这个闭环的关键字是“再次”。架构设计时要把回访、订阅、消息推送、搜索收录都当作一等公民而不是发布页的附属功能。理解了这条主线后续的表结构、接口和任务调度都会围绕它展开。2. 明确核心角色和发现机制再动手写代码2.1 参与角色与使用场景在写第一张表之前先列出系统要服务的角色和场景避免后面反复改表结构。角色主要诉求典型使用场景创始人建立档案、发布更新、进入推荐池创建项目页每周发布一条里程碑早期用户跟踪感兴趣的产品参与讨论收藏项目在 Feed 中查看更新投资人 / 媒体按赛道筛选项目快速了解产品进展搜索“SaaS 融资”订阅垂直标签平台运营审核内容、发现热门话题、治理垃圾信息处理举报标记低质量项目运营专题不同角色的使用路径差异很大。创始人需要的是“写”用户需要的是“看”投资人和媒体需要的是“查”。系统的数据模型必须同时满足写入、读取、聚合检索三类需求这就是为什么不能只做一个博客式的项目列表。2.2 核心领域实体从业务对象出发至少要建模以下实体member用户账号保存注册信息和基础资料。startup项目主体关联创始人。launch_event发布事件记录发布平台、时间和流量数据用来做发布前后对比。update_post项目更新包括里程碑、版本发布、融资、招聘、客户案例等内容。tag标签或赛道用于垂直聚合。member_follow用户与项目之间的订阅关系。startup_activity项目动态的事件表用于 Feed 和日志分析。这里特别要解释 launch_event 的价值。立项时很容易忽略它因为它不影响首版功能。但“发布日之后”这个概念必须有“发布日”作为参照。没有 launch_event数据库里就无法回答“这个项目发布 30 天后是否还有新增访问”这类指标问题。2.3 发现机制设计默认发现途径建议按以下顺序实现关注 Feed用户关注某个项目后在首页看到该项目的最新更新。标签页每个项目按赛道打标签标签页聚合同类项目适合做目录式浏览。全站搜索提供关键词搜索解决“我知道需求但不知道产品名”的发现场景。每周摘要定时任务汇总一周内活跃项目通过邮件或站内信触达。热度排序在 Feed 和标签页中用“最近更新 互动量”替代单纯的发布时间排序让老项目也能重新出现在前排。最后一点最容易做废。热度算法不能只算浏览量否则大公司项目永远霸榜。早期建议使用一个简单的加权公式例如score 0.5 * 最近7天浏览量 / 项目历史浏览量 0.3 * 最近7天更新数 0.2 * 最近7天关注新增数这个公式权重可调核心是让“最近仍在行动”的项目获得更多曝光。2.4 与普通社交 Feed 的差异普通社交 Feed 以“人”和“社交关系”为中心展示的是好友动态。LaunchUp 这类平台以“项目”和“持续更新”为中心用户关注的是对象而不是个人情绪。这就带来两个工程差异Feed 聚合的单位是项目更新不是用户发文所以在查询时要按 startup 分组并去重。项目更新有较强的结构化属性比如 update_type 可以区分 MILESTONE、VERSION、FUNDING、HIRING便于用户按类型过滤。设计数据模型时要时刻提醒自己这不是一个通用微博系统所有表字段都应该服务于“持续发现”这个目标。3. 技术选型和整体架构3.1 推荐技术栈LaunchUp 这类社区项目在初始阶段不需要复杂的微服务。技术选型的核心是团队熟悉、迭代快、后续扩展不阻塞。下面是一套比较稳的默认组合。层技术选择理由前端Next.js / ReactSSR 对 SEO 友好适合需要被搜索引擎收录的项目页后端Spring Boot 3 或 NestJS工程结构清晰生态成熟数据库PostgreSQL 16关系型能力完善支持 JSONB 和全文检索缓存Redis缓存热数据、实现 Feed 分页游标和简单限流搜索PostgreSQL 全文检索起步后期可换 Meilisearch前期避免额外组件后期再扩展对象存储S3 / MinIO存放头像、Logo、截图等静态资源定时任务Spring Scheduler 或 xxl-job生成每周摘要、清理过期数据如果团队本身就是前端全栈用 NestJS 会更顺。如果团队以 Java 为主Spring Boot 更方便维护。两种选择都能支撑本文下面的接口实现思路代码示例以 Spring Boot 展示。3.2 为什么起步阶段可以只用 PostgreSQL很多项目一开始就引入 Elasticsearch最后发现数据量根本不需要。PostgreSQL 自带的全文检索在十万级项目、百万级更新的规模内完全够用而且可以和应用事务保持在同一个数据库里减少数据同步问题。需要独立的 Search 引擎时通常是出现了以下信号搜索响应时间持续超过 300 毫秒。需要复杂的同义词、拼音、纠错、分群搜索能力。需要按多种业务维度动态排序且查询模式无法用 SQL 表达。早期建议先用 PostgreSQL 的tsvector加 GIN 索引撑住第一版。这个方案切换成本低一旦确认瓶颈再引入 Meilisearch 或 Elasticsearch 也不迟。3.3 模块划分和目录结构后端项目结构建议按业务模块划分而不是按技术层划分src/main/java/com/launchup/ ├── member/ │ ├── Member.java │ ├── MemberRepository.java │ └── MemberController.java ├── startup/ │ ├── Startup.java │ ├── StartupRepository.java │ └── StartupController.java ├── update/ │ ├── UpdatePost.java │ ├── UpdatePostRepository.java │ └── UpdateController.java ├── feed/ │ ├── FeedService.java │ └── FeedController.java ├── search/ │ └── SearchService.java └── digest/ ├── DigestService.java └── DigestScheduler.java这样组织之后后续加新模块时不会把改动散落在一套以 controller、service、repository 命名的全局目录里。社区项目通常还要加 message、notification、moderation 模块按业务域切分更利于多人协作。4. 数据模型设计把“创始人”和“持续更新”建模成可查询结构4.1 核心建表 SQL先给出一版可落地的 PostgreSQL DDL。这里故意省略了部分外键约束的细节实际生产中要根据团队习惯补齐命名规范。CREATE TABLE member ( id BIGSERIAL PRIMARY KEY, email VARCHAR(255) NOT NULL UNIQUE, name VARCHAR(120) NOT NULL, avatar_url TEXT, bio TEXT, role VARCHAR(40) NOT NULL DEFAULT FOUNDER, created_at TIMESTAMPTZ NOT NULL DEFAULT now() ); CREATE TABLE startup ( id BIGSERIAL PRIMARY KEY, founder_id BIGINT NOT NULL REFERENCES member(id), name VARCHAR(200) NOT NULL, tagline VARCHAR(300), website_url TEXT, logo_url TEXT, description TEXT, stage VARCHAR(40) NOT NULL DEFAULT IDEA, status VARCHAR(20) NOT NULL DEFAULT ACTIVE, created_at TIMESTAMPTZ NOT NULL DEFAULT now(), updated_at TIMESTAMPTZ NOT NULL DEFAULT now() ); CREATE TABLE launch_event ( id BIGSERIAL PRIMARY KEY, startup_id BIGINT NOT NULL REFERENCES startup(id), platform VARCHAR(100), launched_at TIMESTAMPTZ, external_url TEXT, launch_day_traffic INT, created_at TIMESTAMPTZ NOT NULL DEFAULT now() ); CREATE TABLE update_post ( id BIGSERIAL PRIMARY KEY, startup_id BIGINT NOT NULL REFERENCES startup(id), author_id BIGINT NOT NULL REFERENCES member(id), title VARCHAR(200) NOT NULL, content TEXT NOT NULL, update_type VARCHAR(30) NOT NULL DEFAULT MILESTONE, published_at TIMESTAMPTZ NOT NULL DEFAULT now(), created_at TIMESTAMPTZ NOT NULL DEFAULT now() ); CREATE TABLE tag ( id SERIAL PRIMARY KEY, name VARCHAR(60) NOT NULL UNIQUE, slug VARCHAR(80) NOT NULL UNIQUE ); CREATE TABLE startup_tag ( startup_id BIGINT NOT NULL REFERENCES startup(id), tag_id INT NOT NULL REFERENCES tag(id), PRIMARY KEY (startup_id, tag_id) ); CREATE TABLE member_follow ( member_id BIGINT NOT NULL REFERENCES member(id), startup_id BIGINT NOT NULL REFERENCES startup(id), created_at TIMESTAMPTZ NOT NULL DEFAULT now(), PRIMARY KEY (member_id, startup_id) ); CREATE INDEX idx_update_post_published ON update_post (published_at DESC); CREATE INDEX idx_update_post_startup ON update_post (startup_id, published_at DESC);建表时有意识地做了两个设计。第一所有时间字段统一使用TIMESTAMPTZ避免服务器时区和用户时区不一致导致“更新消失”的假象。第二把update_post和launch_event拆成两张表而不是在 startup 表里堆字段。原因在下一节展开。4.2 为什么用 JSONB 存扩展字段早期项目会遇到大量“不确定字段”的场景不同赛道对项目页的信息要求完全不同。一个 AI 项目可能要存模型类型、训练数据一个消费品牌要存电商平台、定价一个开发者工具要存 GitHub 地址、开源协议。如果把这些字段全部建模成 startup 表的列表会越来越宽且大部分列对多数项目没有意义。常见的替代方案是使用 JSONBALTER TABLE startup ADD COLUMN profile JSONB NOT NULL DEFAULT {}::jsonb;JSONB 的优势是灵活但容易被滥用。要设定一个原则需要查询、排序、聚合的字段必须独立成列只有描述性、展示性、低频变化的扩展字段才放进 JSONB。比如stage要用于筛选就不应该塞进 JSONB。而“商业模式描述”“里程碑记录”这类字段适合放在 JSONB 里。4.3 为什么要把“动态”单独建表Feed 系统最怕的一件事是“查一次 Feed 要 join 十张表”。避免这个问题的最佳方式不是优化 join而是提前建一张动态事件表。CREATE TABLE startup_activity ( id BIGSERIAL PRIMARY KEY, startup_id BIGINT NOT NULL REFERENCES startup(id), actor_id BIGINT NOT NULL REFERENCES member(id), activity_type VARCHAR(40) NOT NULL, target_id BIGINT, payload JSONB NOT NULL DEFAULT {}::jsonb, created_at TIMESTAMPTZ NOT NULL DEFAULT now() ); CREATE INDEX idx_startup_activity_startup ON startup_activity (startup_id, created_at DESC);项目发布新版本、新增融资信息、创始人发布更新时都会向这张表写入一条活动记录。Feed 只查这张表拿到 activity_type 和 target_id 之后再按需补充详情。这套模式叫事件回放比直接 join 业务表简单也更容易扩展新动态类型。4.4 索引和分页方案Feed 查询最常见的形态是“某个用户关注的 N 个项目里最近更新的动态”。这个查询有两个瓶颈关注项目数量可能很大动态排序需要按时间倒序。建议给 update_post 和 startup_activity 都建立(startup_id, published_at DESC)或(startup_id, created_at DESC)的复合索引。分页不要用OFFSET因为社区 Feed 在持续追加用户翻页时容易出现重复数据。推荐使用游标分页以最后一条动态的时间作为下一页的起点。数据库层的写法类似SELECT * FROM update_post WHERE startup_id IN (:startupIds) AND published_at :cursor ORDER BY published_at DESC LIMIT 20;游标的优势是稳定、高效能避免深翻页时数据库扫描大量偏移行的问题。后面接口实现会展示如何在 Spring Data JPA 中写这个查询。5. 核心接口和关键代码实现5.1 创建创始人档案和项目先定义一个简单的CreateStartupRequest记录。这里省略 getter/setter实际项目可以用 Lombok 或 Java record 简化。public record CreateStartupRequest( String name, String tagline, String description, String stage, ListLong tagIds ) {}Controller 层保持薄只负责参数接收和响应封装RestController RequestMapping(/api/startups) public class StartupController { private final StartupRepository startupRepository; private final StartupTagRepository startupTagRepository; public StartupController(StartupRepository startupRepository, StartupTagRepository startupTagRepository) { this.startupRepository startupRepository; this.startupTagRepository startupTagRepository; } PostMapping public Startup create(RequestBody CreateStartupRequest request) { Startup startup new Startup(); startup.setName(request.name()); startup.setTagline(request.tagline()); startup.setDescription(request.description()); startup.setStage(StartupStage.valueOf(request.stage())); startup startupRepository.save(startup); if (request.tagIds() ! null) { for (Long tagId : request.tagIds()) { startupTagRepository.insert(startup.getId(), tagId); } } return startup; } }实际项目不要忘记设置 founder_id并做权限校验只有登录用户才能创建项目且不能创建别人的项目。这里的代码只是为了演示主流程。5.2 发布更新并写入活动流发布更新是最关键的一个动作。它的职责不只是插入一条 update_post还要写入 startup_activity同时刷新 startup 的 updated_at。为了保证这两个动作要么都成功、要么都失败必须放在同一个事务里。Service public class UpdateService { private final UpdatePostRepository updatePostRepository; private final StartupActivityRepository activityRepository; private final StartupRepository startupRepository; Transactional public UpdatePost publish(UpdatePostRequest request) { UpdatePost post new UpdatePost(); post.setStartupId(request.startupId()); post.setAuthorId(request.authorId()); post.setTitle(request.title()); post.setContent(request.content()); post.setUpdateType(request.updateType()); post.setPublishedAt(Instant.now()); updatePostRepository.save(post); StartupActivity activity new StartupActivity(); activity.setStartupId(request.startupId()); activity.setActorId(request.authorId()); activity.setActivityType(UPDATE_POST); activity.setTargetId(post.getId()); activity.setPayload(Map.of(title, post.getTitle())); activityRepository.save(activity); startupRepository.touch(request.startupId()); return post; } }这里touch是一个自定义更新语句只更新 updated_at 字段减少不必要的整行更新Modifying Query(UPDATE Startup s SET s.updatedAt :now WHERE s.id :id) int touch(Param(id) Long id, Param(now) Instant now);更新的写路径只有两部分业务数据写入事件表元数据更新时间。这样 Feed 读到新动态时项目本身也必然被标记为“近期活跃”热度排序才能生效。5.3 首页发现 Feed首页 Feed 的任务是取当前用户关注的所有项目按最近更新时间倒序返回动态列表。用 Spring Data JPA 可以这样写public interface UpdatePostRepository extends JpaRepositoryUpdatePost, Long { Query( SELECT up FROM UpdatePost up WHERE up.startupId IN :startupIds AND (:cursor IS NULL OR up.publishedAt :cursor) ORDER BY up.publishedAt DESC LIMIT :limit ) ListUpdatePost findFollowingFeed( Param(startupIds) ListLong startupIds, Param(cursor) Instant cursor, Param(limit) int limit); }FeedService 负责拼装游标和响应结构Service public class FeedService { private final MemberFollowRepository followRepository; private final UpdatePostRepository updatePostRepository; public FeedResult getFeed(Long memberId, Instant cursor, int limit) { ListLong startupIds followRepository.findStartupIdsByMemberId(memberId); if (startupIds.isEmpty()) { return FeedResult.empty(); } ListUpdatePost items updatePostRepository.findFollowingFeed(startupIds, cursor, limit); Instant nextCursor items.isEmpty() ? null : items.get(items.size() - 1).getPublishedAt(); return new FeedResult(items, nextCursor); } }这里返回的 nextCursor 要特别注意。Feed 里可能有多条动态发布时间完全相同如果只用时间做游标会漏掉同秒数据。生产方案通常改用“时间戳 主键 ID”组成复合游标例如publishedAt_from_currentItem_id。早期可以先接受时间游标但要意识到这个边界。5.4 搜索与标签页早期使用 PostgreSQL 全文检索时先给 startup 表增加一个生成列ALTER TABLE startup ADD COLUMN search_doc tsvector GENERATED ALWAYS AS ( setweight(to_tsvector(simple, coalesce(name, )), A) || setweight(to_tsvector(simple, coalesce(tagline, )), B) || setweight(to_tsvector(simple, coalesce(description, )), C) ) STORED; CREATE INDEX startup_search_idx ON startup USING GIN (search_doc);搜索接口的核心查询Query(value SELECT id, name, tagline, stage FROM startup WHERE search_doc websearch_to_tsquery(simple, :keyword) ORDER BY ts_rank(search_doc, websearch_to_tsquery(simple, :keyword)) DESC LIMIT :limit , nativeQuery true) ListStartupSearchResult search(Param(keyword) String keyword, Param(limit) int limit);setweight的作用是给不同字段设置不同优先级。名称命中比描述命中更重要所以在排序时权重更高。首次查询注意用websearch_to_tsquery而不是to_tsquery因为websearch_to_tsquery对普通用户输入更友好能容忍引号、空格等特殊字符。标签页不需要搜索索引直接按 startup_tag 和 tag 两表 join 即可SELECT s.id, s.name, s.tagline FROM startup s JOIN startup_tag st ON st.startup_id s.id WHERE st.tag_id :tagId ORDER BY s.updated_at DESC LIMIT 20;为了让标签页持续呈现“活项目”这里按 updated_at 排序而不是 created_at。一个三天前发布但持续更新的项目应该排在三个月前发布但从未更新的项目前面。这个排序逻辑才是“发布日之后继续被发现”在产品里的直接体现。5.5 每周摘要邮件的生成每周摘要用定时任务生成。任务分三步筛选最近 7 天有更新的项目按标签分组生成 HTML 邮件并发送。Component public class DigestScheduler { private final DigestService digestService; private final MailService mailService; Scheduled(cron 0 0 9 * * MON) public void sendWeeklyDigest() { ListDigestItem items digestService.findLastWeekActiveStartups(); MapString, ListDigestItem grouped items.stream() .collect(Collectors.groupingBy(DigestItem::tagName)); ListMember subscribers digestService.findSubscribers(); for (Member subscriber : subscribers) { String html renderDigest(grouped, subscriber); mailService.send(subscriber.getEmail(), 本周值得关注的创始人项目, html); } } }定时任务里最容易出的问题是在大数据量下逐个用户发送邮件导致任务积压。生产环境要改成两步先生成待发送任务写入 teamwork 队列再由发送线程或外部任务平台消费。学习环境先把单线程跑通即可。6. 本地运行和验证6.1 环境准备建议本地环境如下组件版本要求用途JDK17 以上运行 Spring Boot 应用Maven3.8 以上依赖管理Docker20.10 以上启动 PostgreSQL 和 RedisPostgreSQL16主数据库Redis7缓存和简单限流如果机器已经装了 PostgreSQL也可以直接用本机数据库。下面的步骤以 Docker Compose 为例便于一条命令恢复环境。6.2 启动依赖服务在项目根目录创建docker-compose.ymlversion: 3.8 services: postgres: image: postgres:16 environment: POSTGRES_DB: launchup POSTGRES_USER: launchup POSTGRES_PASSWORD: launchup ports: - 5432:5432 volumes: - pgdata:/var/lib/postgresql/data redis: image: redis:7 ports: - 6379:6379 volumes: pgdata:执行启动命令docker compose up -d验证 PostgreSQL 和 Redis 是否就绪docker compose ps看到两个服务的状态都为 running 后接着配置应用。在application.yml中连接数据库和 Redisspring: datasource: url: jdbc:postgresql://localhost:5432/launchup username: launchup password: launchup jpa: hibernate: ddl-auto: none show-sql: false data: redis: host: localhost port: 6379这里把ddl-auto设为none。生产或学习环境都不建议用 Hibernate 自动建表表结构应该由初始化 SQL 或 Flyway 之类的迁移工具管理。6.3 启动应用并用 curl 验证启动后端./mvnw spring-boot:run应用默认在 8080 端口启动。先创建一个项目curl -X POST http://localhost:8080/api/startups \ -H Content-Type: application/json \ -d { name: LaunchUp, tagline: 让创始人在发布日之后持续被发现的社区, description: 帮助创始人建立档案、发布更新、进入推荐池的社区平台, stage: MVP, tagIds: [1, 2] }预期返回类似结构{ id: 1, name: LaunchUp, tagline: 让创始人在发布日之后持续被发现的社区, stage: MVP, createdAt: 2025-01-01T10:00:00Z }再发布一条更新curl -X POST http://localhost:8080/api/startups/1/updates \ -H Content-Type: application/json \ -d { title: LaunchUp 第一版社区 Feed 完成, content: 用户现在可以关注项目并接收最新动态, updateType: MILESTONE }请求首页 Feedcurl http://localhost:8080/api/feed?memberId1limit20如果没有数据先检查成员是否关注了项目。Feed 只返回“已关注项目”的动态这一点在验证时最容易混淆。6.4 预期输出和检查点接口正常结果常见异常POST /api/startups返回新项目对象id 自增参数校验失败返回 400POST /api/startups/1/updates返回更新对象并写入活动表项目不存在返回 404GET /api/feed返回已关注项目的动态列表未关注任何项目时返回空列表GET /api/search?keywordLaunchUp返回名称命中结果无匹配时返回空数组到这里最小闭环已经跑通创建项目、发布更新、订阅关注、Feed 输出、搜索命中。这五个动作覆盖了“发布日之后被持续发现”的核心链路。6.5 学习环境与生产环境的区别本地跑通不代表可以上线。下表是一次明显的能力分界维度学习环境生产环境数据库迁移手动执行 SQLFlyway / Liquibase 版本化错误响应返回默认错误页面统一错误码和日志追踪 ID图片存储本地目录对象存储加 CDN定时任务单机 Scheduler分布式调度加幂等控制搜索PostgreSQL 全文检索视数据量决定是否引入独立搜索引擎垃圾内容不做处理需要审核队列、举报、封禁机制监控无日志、指标、告警、慢查询分析如果直接拿学习环境的工程结构上生产第一批用户进来后就会遇到图片无法访问、邮件任务超时、垃圾内容刷屏、数据库连接池被慢查询打满等问题。7. 常见问题与排查路径7.1 Feed 出现重复或丢失动态现象用户关注多个项目后翻页时看到重复动态或者某个项目的更新没出现在 Feed 里。可能原因分页使用 OFFSET新数据插入后页边界移动。“关注项目列表”为空但前端仍然发起了分页请求。更新写入时没有同步写入 startup_activity导致 Feed 和趋势页数据不一致。排查方式查看关联查询 SQL确认启动项目列表是否包含对应 startup_id。检查 update_post 和 startup_activity 两个表同一时间点的新增记录数是否一致。在翻页请求中打印 cursor观察下一轮请求是否使用了正确游标。修复方式全面改用游标分页发布更新的写路径需要事务保证两表同时写入如果历史数据已经不一致就写一个对账脚本以 update_post 为准补写缺失的事件。7.2 时区导致更新时间错位现象项目明明在本地时间 23 点发布了更新第二天发现摘要邮件里没有这条动态。可能原因数据库存储使用timestamp without time zone应用服务器和数据库服务器时区不一致。定时任务使用服务器本地时间计算“最近 7 天”而服务器时区不是目标用户时区。前端渲染时间直接把 UTC 时间转为字符串导致展示偏移。排查方式执行show timezone;查看 PostgreSQL 时区。用SELECT published_at AT TIME ZONE UTC FROM update_post;对比。查看应用日志中定时任务的触发时间和实际执行时间。修复方式所有时间字段统一使用TIMESTAMPTZ定时任务使用固定时区比如Asia/Shanghai计算窗口前端使用 ISO 8601 格式传输时间由浏览器本地渲染。这样能避免服务器时区漂移影响业务判断。7.3 搜索索引与业务数据不一致现象新创建的项目在数据库里查得到但搜索接口返回不了。可能原因使用独立搜索引擎时没有建立同步任务或同步任务失败。使用 PostgreSQL 生成列时旧数据没有回填。关键词输入包含引号、标点全文检索函数解析失败。排查方式查询项目是否存在SELECT * FROM startup WHERE id 1;检查搜索索引文档是否更新SELECT id, search_doc FROM startup WHERE id 1;直接执行搜索 SQL 看是否有语法错误。修复方式首次上线先做全量索引任务新数据通过事务内同步或异步消息补偿。如果生成列已经建立但旧数据为空执行一次REINDEX或手动更新即可。对普通用户贡献的搜索词进行处理时优先使用websearch_to_tsquery而不是裸to_tsquery。7.4 N1 查询导致 Feed 变慢现象Feed 接口在只有 100 条动态时就消耗 300ms 以上数据量增长后越来越慢。可能原因循环查询每个 startup 的详情。循环查询每个 update_post 的作者和项目。在循环里多次访问缓存。排查方式打开 Hibernate 的 SQL 日志统计一次 Feed 请求实际执行的 SQL 条数。用EXPLAIN ANALYZE检查核心查询是否命中了(startup_id, published_at DESC)索引。修复方式关联数据一次性查出比如 Feed 查询结果出来后用IN批量查项目和作者把项目名称、Logo 等高频字段放入缓存或者直接在 startup_activity 的 payload 里冗余一份标题、项目名减少回表。7.5 深翻页导致接口超时现象用户翻到第 50 页之后接口响应明显变慢甚至超时。可能原因还是用了 OFFSET 翻页数据库扫描了大量已读行。排序字段没有索引或索引顺序不正确。查询条件缺少 startupIds 边界导致全表扫描。排查方式看慢查询日志确认 SQL 的 rows 扫描数和返回数差异。用EXPLAIN查看索引是否被使用。修复方式全站统一使用游标分页确认published_at和startup_id的复合索引方向对 Feed 和搜索接口设置最长分页深度超过深度的请求直接返回空数据并引导用户使用筛选条件。7.6 常见问题速查表问题现象常见原因检查方式处理建议发布更新后 Feed 不出现写入未提交或活动表未同步查看数据库日志和 startup_activity统一事务补写事件翻页出现重复动态使用 OFFSET 分页打印分页参数和结果 ID改游标分页搜索找不到新项目索引没同步比较数据库和索引数据量补全量索引任务首页加载慢N1 查询开启 SQL 日志统计条数批量查询加缓存摘要邮件缺少某项目时间窗口算错检查定时任务时区统一 TIMESTAMPTZ 和固定时区热门列表被老项目霸榜排序只看历史流量检查 score 计算日志引入近期更新和活跃加权8. 最佳实践与扩展方向8.1 把“持续发现”做成产品机制而不是页面字段很多团队会把“发布日之后继续被发现”理解为在项目页加一个“最新动态”栏。这对但远远不够。真正的持续发现要建立在三条产品机制上有周期性触达每周摘要、通知、专题页。有可检索入口标签、搜索、赛道目录。有活跃度信号项目更新会重新进入 Feed 和搜索排序。工程实现上这三条机制的共同基础设施就是事件表加活动流。只要所有业务动作都写入 startup_activity后续加通知、加推荐、加数据报表都只是对事件表的查询和组织。8.2 内容治理和反垃圾创始人社区比普通 UGC 平台更容易被广告号、招聘号、营销号盯上。上线前至少要有创建项目和发布更新前做登录校验。对 URL、联系方式等敏感内容做正则或关键词过滤。设置发布频率限制防止单用户短时间内刷屏。运营后台支持标记、隐藏、删除项目。对搜索接口做限流避免被爬虫拖垮。学习环境可以不实现这些但它们应该被写进系统设计文档保证后续迭代时不会被遗忘。8.3 关键指标“发布日之后有没有被持续发现”不能只靠感觉。建议上线后第一周就埋好以下指标指标计算口径说明发布后 30 天回访率发布后 30 天内再次访问项目页的用户数 / 发布日访问用户数衡量内容后续吸引能力活跃项目占比最近 30 天有更新的项目数 / 全部上架项目数衡量平台生命力标签页点击率标签页点击次数 / 标签页展示次数衡量目录式发现是否有效摘要邮件打开率打开邮件用户数 / 发送邮件用户数衡量周期性触达质量Feed 平均卡顿时间用户从打开 Feed 到看到首条动态的耗时衡量接口性能这些指标不需要一开始就做成完整数据平台先通过日志和定时统计记到一张 daily_metric 表里即可。但字段口径要在第一版就固定否则后期换口径无法横向对比。8.4 上线前检查清单数据库迁移脚本是否有版本控制。所有外键和时间字段是否统一使用建议类型。Feed 分页是否使用游标。发布更新和活动写入是否在同一事务内。搜索索引是否支持全量初始化。图片是否走对象存储而不是本地磁盘。邮件发送是否有失败重试机制。定时任务是否具备幂等性。是否有内容审核和举报入口。是否有基本监控和错误日志追踪。8.5 扩展方向第一版跑通后可以从以下方向扩展个性化推荐基于用户关注标签和浏览历史对 Feed 做重排序。社区讨论允许用户在项目下发起问答和评论把项目页变成对话场所。创始人访谈和专题由运营制作深度内容将分散项目串成主题故事。数据图谱展示创始人历史项目、投资关系、合作伙伴形成更丰富的身份档案。开放接口让第三方工具可以通过 API 查询项目状态和更新记录。扩展时最需要守住的底线是不要破坏“项目为中心”的信息模型。一旦把关注重心从项目转移到泛社交关系系统就会偏离最初要解决的“发布日之后持续被发现”的问题。如果把整个系统抽象成一句话不要把创始人的价值压缩在发布日那一天而是让平台能够回答“这个创始人最近在做什么、解决什么问题、值不值得关注”。工程上的任务就是让这三个问题变得可检索、可订阅、可量化。LaunchUp 这类社区能否真正胜出不取决于发布页做得有多炫而取决于发布后 30 天、90 天用户能不能持续在这里重新遇见一个有进展、有观点、有行动力的创始人。 构建创始人持续发现社区：产品发布后的Feed、搜索与数据模型设计
做产品发布的人都会遇到同一个现象新品上线当天流量、注册、媒体曝光全部冲高随后几天快速回落最后变成一条几乎不产生新发现的冷数据。创始人需要的并不是一次性曝光而是在发布日之后仍然有稳定渠道被潜在用户、合作伙伴和早期投资人发现。LaunchUp 正是围绕这个命题出现的社区项目它不只在发布当天把产品递出去而是把创始人档案、产品更新、话题标签、持续动态组织成一套长期可检索、可订阅、可推荐的信息系统。从工程角度拆开看这个需求会直接决定数据模型、Feed 结构、搜索方案和内容分发机制。这篇文章从一个可实现的社区系统出发梳理这类平台的设计思路、技术栈选择、数据表结构、核心接口实现以及上线后最常遇到的问题和排查方法。1. 先理解“发布日之后如何被持续发现”这个命题1.1 发布日流量为什么留不住大多数产品发布平台的流量曲线是典型的“脉冲型”。发布当天产品页通过首页推荐、社交媒体转发、邮件外推获得一个流量高峰之后因为缺少新的内容更新和新的互动信号页面权重快速下降几乎不再进入普通用户的视野。这里的问题不是发布渠道不够多而是信息架构没有为“持续发现”做设计。一次发布会带来三个结果产品页面、一批截图、一堆外部链接。这三点在发布结束后都是静态信息。静态信息只能被“检索到一次”很难被“反复遇见”。真正的长效发现依赖三个能力创始人或团队有可识别的身份档案和主题领域。产品持续产生新的更新、里程碑、案例或社区讨论。平台有机制把上述信息主动推给对它感兴趣的人比如关注流、订阅邮件、标签页和搜索。这三点缺任何一个发布日之后都会失去发现入口。1.2 从产品口号反推工程需求把“帮助创始人在发布日之后持续被发现”当作一个技术需求来拆解会得到一组非常具体的功能关键词创始人档案页访问者可以了解这个人在做什么、在哪条赛道、有什么历史背景。项目页和更新流展示产品从发布到后期迭代的完整时间线。标签与话题把分散的创始人按 AI、SaaS、开发者工具、消费品牌等赛道聚合成垂直列表。关注与订阅用户可以选择关注某个项目或某个创始人之后在 Feed 里看到持续动态。全站搜索让新用户通过关键词找到已经发布 30 天、90 天甚至更久的项目。周期性触达每周摘要邮件、热门项目推送把已经“沉默”的项目重新带回用户视野。这些功能每一条都不复杂但组合起来就构成了一个可持续运营的信息闭环。工程上最难的部分不是单个功能而是这些功能共享同一套数据模型并且要在一套 Feed 和搜索体系里保持一致。1.3 平台的信息闭环LaunchUp 这类社区的信息循环可以抽象成五步创始人创建档案并提交项目。项目进入标签池被初始分类收录。项目发布后产生首批访问访问者可以选择关注。创始人持续发布更新关注者在 Feed 中收到新的动态。每周摘要或搜索再次推荐项目让错过首发的人重新发现它。这个闭环的关键字是“再次”。架构设计时要把回访、订阅、消息推送、搜索收录都当作一等公民而不是发布页的附属功能。理解了这条主线后续的表结构、接口和任务调度都会围绕它展开。2. 明确核心角色和发现机制再动手写代码2.1 参与角色与使用场景在写第一张表之前先列出系统要服务的角色和场景避免后面反复改表结构。角色主要诉求典型使用场景创始人建立档案、发布更新、进入推荐池创建项目页每周发布一条里程碑早期用户跟踪感兴趣的产品参与讨论收藏项目在 Feed 中查看更新投资人 / 媒体按赛道筛选项目快速了解产品进展搜索“SaaS 融资”订阅垂直标签平台运营审核内容、发现热门话题、治理垃圾信息处理举报标记低质量项目运营专题不同角色的使用路径差异很大。创始人需要的是“写”用户需要的是“看”投资人和媒体需要的是“查”。系统的数据模型必须同时满足写入、读取、聚合检索三类需求这就是为什么不能只做一个博客式的项目列表。2.2 核心领域实体从业务对象出发至少要建模以下实体member用户账号保存注册信息和基础资料。startup项目主体关联创始人。launch_event发布事件记录发布平台、时间和流量数据用来做发布前后对比。update_post项目更新包括里程碑、版本发布、融资、招聘、客户案例等内容。tag标签或赛道用于垂直聚合。member_follow用户与项目之间的订阅关系。startup_activity项目动态的事件表用于 Feed 和日志分析。这里特别要解释 launch_event 的价值。立项时很容易忽略它因为它不影响首版功能。但“发布日之后”这个概念必须有“发布日”作为参照。没有 launch_event数据库里就无法回答“这个项目发布 30 天后是否还有新增访问”这类指标问题。2.3 发现机制设计默认发现途径建议按以下顺序实现关注 Feed用户关注某个项目后在首页看到该项目的最新更新。标签页每个项目按赛道打标签标签页聚合同类项目适合做目录式浏览。全站搜索提供关键词搜索解决“我知道需求但不知道产品名”的发现场景。每周摘要定时任务汇总一周内活跃项目通过邮件或站内信触达。热度排序在 Feed 和标签页中用“最近更新 互动量”替代单纯的发布时间排序让老项目也能重新出现在前排。最后一点最容易做废。热度算法不能只算浏览量否则大公司项目永远霸榜。早期建议使用一个简单的加权公式例如score 0.5 * 最近7天浏览量 / 项目历史浏览量 0.3 * 最近7天更新数 0.2 * 最近7天关注新增数这个公式权重可调核心是让“最近仍在行动”的项目获得更多曝光。2.4 与普通社交 Feed 的差异普通社交 Feed 以“人”和“社交关系”为中心展示的是好友动态。LaunchUp 这类平台以“项目”和“持续更新”为中心用户关注的是对象而不是个人情绪。这就带来两个工程差异Feed 聚合的单位是项目更新不是用户发文所以在查询时要按 startup 分组并去重。项目更新有较强的结构化属性比如 update_type 可以区分 MILESTONE、VERSION、FUNDING、HIRING便于用户按类型过滤。设计数据模型时要时刻提醒自己这不是一个通用微博系统所有表字段都应该服务于“持续发现”这个目标。3. 技术选型和整体架构3.1 推荐技术栈LaunchUp 这类社区项目在初始阶段不需要复杂的微服务。技术选型的核心是团队熟悉、迭代快、后续扩展不阻塞。下面是一套比较稳的默认组合。层技术选择理由前端Next.js / ReactSSR 对 SEO 友好适合需要被搜索引擎收录的项目页后端Spring Boot 3 或 NestJS工程结构清晰生态成熟数据库PostgreSQL 16关系型能力完善支持 JSONB 和全文检索缓存Redis缓存热数据、实现 Feed 分页游标和简单限流搜索PostgreSQL 全文检索起步后期可换 Meilisearch前期避免额外组件后期再扩展对象存储S3 / MinIO存放头像、Logo、截图等静态资源定时任务Spring Scheduler 或 xxl-job生成每周摘要、清理过期数据如果团队本身就是前端全栈用 NestJS 会更顺。如果团队以 Java 为主Spring Boot 更方便维护。两种选择都能支撑本文下面的接口实现思路代码示例以 Spring Boot 展示。3.2 为什么起步阶段可以只用 PostgreSQL很多项目一开始就引入 Elasticsearch最后发现数据量根本不需要。PostgreSQL 自带的全文检索在十万级项目、百万级更新的规模内完全够用而且可以和应用事务保持在同一个数据库里减少数据同步问题。需要独立的 Search 引擎时通常是出现了以下信号搜索响应时间持续超过 300 毫秒。需要复杂的同义词、拼音、纠错、分群搜索能力。需要按多种业务维度动态排序且查询模式无法用 SQL 表达。早期建议先用 PostgreSQL 的tsvector加 GIN 索引撑住第一版。这个方案切换成本低一旦确认瓶颈再引入 Meilisearch 或 Elasticsearch 也不迟。3.3 模块划分和目录结构后端项目结构建议按业务模块划分而不是按技术层划分src/main/java/com/launchup/ ├── member/ │ ├── Member.java │ ├── MemberRepository.java │ └── MemberController.java ├── startup/ │ ├── Startup.java │ ├── StartupRepository.java │ └── StartupController.java ├── update/ │ ├── UpdatePost.java │ ├── UpdatePostRepository.java │ └── UpdateController.java ├── feed/ │ ├── FeedService.java │ └── FeedController.java ├── search/ │ └── SearchService.java └── digest/ ├── DigestService.java └── DigestScheduler.java这样组织之后后续加新模块时不会把改动散落在一套以 controller、service、repository 命名的全局目录里。社区项目通常还要加 message、notification、moderation 模块按业务域切分更利于多人协作。4. 数据模型设计把“创始人”和“持续更新”建模成可查询结构4.1 核心建表 SQL先给出一版可落地的 PostgreSQL DDL。这里故意省略了部分外键约束的细节实际生产中要根据团队习惯补齐命名规范。CREATE TABLE member ( id BIGSERIAL PRIMARY KEY, email VARCHAR(255) NOT NULL UNIQUE, name VARCHAR(120) NOT NULL, avatar_url TEXT, bio TEXT, role VARCHAR(40) NOT NULL DEFAULT FOUNDER, created_at TIMESTAMPTZ NOT NULL DEFAULT now() ); CREATE TABLE startup ( id BIGSERIAL PRIMARY KEY, founder_id BIGINT NOT NULL REFERENCES member(id), name VARCHAR(200) NOT NULL, tagline VARCHAR(300), website_url TEXT, logo_url TEXT, description TEXT, stage VARCHAR(40) NOT NULL DEFAULT IDEA, status VARCHAR(20) NOT NULL DEFAULT ACTIVE, created_at TIMESTAMPTZ NOT NULL DEFAULT now(), updated_at TIMESTAMPTZ NOT NULL DEFAULT now() ); CREATE TABLE launch_event ( id BIGSERIAL PRIMARY KEY, startup_id BIGINT NOT NULL REFERENCES startup(id), platform VARCHAR(100), launched_at TIMESTAMPTZ, external_url TEXT, launch_day_traffic INT, created_at TIMESTAMPTZ NOT NULL DEFAULT now() ); CREATE TABLE update_post ( id BIGSERIAL PRIMARY KEY, startup_id BIGINT NOT NULL REFERENCES startup(id), author_id BIGINT NOT NULL REFERENCES member(id), title VARCHAR(200) NOT NULL, content TEXT NOT NULL, update_type VARCHAR(30) NOT NULL DEFAULT MILESTONE, published_at TIMESTAMPTZ NOT NULL DEFAULT now(), created_at TIMESTAMPTZ NOT NULL DEFAULT now() ); CREATE TABLE tag ( id SERIAL PRIMARY KEY, name VARCHAR(60) NOT NULL UNIQUE, slug VARCHAR(80) NOT NULL UNIQUE ); CREATE TABLE startup_tag ( startup_id BIGINT NOT NULL REFERENCES startup(id), tag_id INT NOT NULL REFERENCES tag(id), PRIMARY KEY (startup_id, tag_id) ); CREATE TABLE member_follow ( member_id BIGINT NOT NULL REFERENCES member(id), startup_id BIGINT NOT NULL REFERENCES startup(id), created_at TIMESTAMPTZ NOT NULL DEFAULT now(), PRIMARY KEY (member_id, startup_id) ); CREATE INDEX idx_update_post_published ON update_post (published_at DESC); CREATE INDEX idx_update_post_startup ON update_post (startup_id, published_at DESC);建表时有意识地做了两个设计。第一所有时间字段统一使用TIMESTAMPTZ避免服务器时区和用户时区不一致导致“更新消失”的假象。第二把update_post和launch_event拆成两张表而不是在 startup 表里堆字段。原因在下一节展开。4.2 为什么用 JSONB 存扩展字段早期项目会遇到大量“不确定字段”的场景不同赛道对项目页的信息要求完全不同。一个 AI 项目可能要存模型类型、训练数据一个消费品牌要存电商平台、定价一个开发者工具要存 GitHub 地址、开源协议。如果把这些字段全部建模成 startup 表的列表会越来越宽且大部分列对多数项目没有意义。常见的替代方案是使用 JSONBALTER TABLE startup ADD COLUMN profile JSONB NOT NULL DEFAULT {}::jsonb;JSONB 的优势是灵活但容易被滥用。要设定一个原则需要查询、排序、聚合的字段必须独立成列只有描述性、展示性、低频变化的扩展字段才放进 JSONB。比如stage要用于筛选就不应该塞进 JSONB。而“商业模式描述”“里程碑记录”这类字段适合放在 JSONB 里。4.3 为什么要把“动态”单独建表Feed 系统最怕的一件事是“查一次 Feed 要 join 十张表”。避免这个问题的最佳方式不是优化 join而是提前建一张动态事件表。CREATE TABLE startup_activity ( id BIGSERIAL PRIMARY KEY, startup_id BIGINT NOT NULL REFERENCES startup(id), actor_id BIGINT NOT NULL REFERENCES member(id), activity_type VARCHAR(40) NOT NULL, target_id BIGINT, payload JSONB NOT NULL DEFAULT {}::jsonb, created_at TIMESTAMPTZ NOT NULL DEFAULT now() ); CREATE INDEX idx_startup_activity_startup ON startup_activity (startup_id, created_at DESC);项目发布新版本、新增融资信息、创始人发布更新时都会向这张表写入一条活动记录。Feed 只查这张表拿到 activity_type 和 target_id 之后再按需补充详情。这套模式叫事件回放比直接 join 业务表简单也更容易扩展新动态类型。4.4 索引和分页方案Feed 查询最常见的形态是“某个用户关注的 N 个项目里最近更新的动态”。这个查询有两个瓶颈关注项目数量可能很大动态排序需要按时间倒序。建议给 update_post 和 startup_activity 都建立(startup_id, published_at DESC)或(startup_id, created_at DESC)的复合索引。分页不要用OFFSET因为社区 Feed 在持续追加用户翻页时容易出现重复数据。推荐使用游标分页以最后一条动态的时间作为下一页的起点。数据库层的写法类似SELECT * FROM update_post WHERE startup_id IN (:startupIds) AND published_at :cursor ORDER BY published_at DESC LIMIT 20;游标的优势是稳定、高效能避免深翻页时数据库扫描大量偏移行的问题。后面接口实现会展示如何在 Spring Data JPA 中写这个查询。5. 核心接口和关键代码实现5.1 创建创始人档案和项目先定义一个简单的CreateStartupRequest记录。这里省略 getter/setter实际项目可以用 Lombok 或 Java record 简化。public record CreateStartupRequest( String name, String tagline, String description, String stage, ListLong tagIds ) {}Controller 层保持薄只负责参数接收和响应封装RestController RequestMapping(/api/startups) public class StartupController { private final StartupRepository startupRepository; private final StartupTagRepository startupTagRepository; public StartupController(StartupRepository startupRepository, StartupTagRepository startupTagRepository) { this.startupRepository startupRepository; this.startupTagRepository startupTagRepository; } PostMapping public Startup create(RequestBody CreateStartupRequest request) { Startup startup new Startup(); startup.setName(request.name()); startup.setTagline(request.tagline()); startup.setDescription(request.description()); startup.setStage(StartupStage.valueOf(request.stage())); startup startupRepository.save(startup); if (request.tagIds() ! null) { for (Long tagId : request.tagIds()) { startupTagRepository.insert(startup.getId(), tagId); } } return startup; } }实际项目不要忘记设置 founder_id并做权限校验只有登录用户才能创建项目且不能创建别人的项目。这里的代码只是为了演示主流程。5.2 发布更新并写入活动流发布更新是最关键的一个动作。它的职责不只是插入一条 update_post还要写入 startup_activity同时刷新 startup 的 updated_at。为了保证这两个动作要么都成功、要么都失败必须放在同一个事务里。Service public class UpdateService { private final UpdatePostRepository updatePostRepository; private final StartupActivityRepository activityRepository; private final StartupRepository startupRepository; Transactional public UpdatePost publish(UpdatePostRequest request) { UpdatePost post new UpdatePost(); post.setStartupId(request.startupId()); post.setAuthorId(request.authorId()); post.setTitle(request.title()); post.setContent(request.content()); post.setUpdateType(request.updateType()); post.setPublishedAt(Instant.now()); updatePostRepository.save(post); StartupActivity activity new StartupActivity(); activity.setStartupId(request.startupId()); activity.setActorId(request.authorId()); activity.setActivityType(UPDATE_POST); activity.setTargetId(post.getId()); activity.setPayload(Map.of(title, post.getTitle())); activityRepository.save(activity); startupRepository.touch(request.startupId()); return post; } }这里touch是一个自定义更新语句只更新 updated_at 字段减少不必要的整行更新Modifying Query(UPDATE Startup s SET s.updatedAt :now WHERE s.id :id) int touch(Param(id) Long id, Param(now) Instant now);更新的写路径只有两部分业务数据写入事件表元数据更新时间。这样 Feed 读到新动态时项目本身也必然被标记为“近期活跃”热度排序才能生效。5.3 首页发现 Feed首页 Feed 的任务是取当前用户关注的所有项目按最近更新时间倒序返回动态列表。用 Spring Data JPA 可以这样写public interface UpdatePostRepository extends JpaRepositoryUpdatePost, Long { Query( SELECT up FROM UpdatePost up WHERE up.startupId IN :startupIds AND (:cursor IS NULL OR up.publishedAt :cursor) ORDER BY up.publishedAt DESC LIMIT :limit ) ListUpdatePost findFollowingFeed( Param(startupIds) ListLong startupIds, Param(cursor) Instant cursor, Param(limit) int limit); }FeedService 负责拼装游标和响应结构Service public class FeedService { private final MemberFollowRepository followRepository; private final UpdatePostRepository updatePostRepository; public FeedResult getFeed(Long memberId, Instant cursor, int limit) { ListLong startupIds followRepository.findStartupIdsByMemberId(memberId); if (startupIds.isEmpty()) { return FeedResult.empty(); } ListUpdatePost items updatePostRepository.findFollowingFeed(startupIds, cursor, limit); Instant nextCursor items.isEmpty() ? null : items.get(items.size() - 1).getPublishedAt(); return new FeedResult(items, nextCursor); } }这里返回的 nextCursor 要特别注意。Feed 里可能有多条动态发布时间完全相同如果只用时间做游标会漏掉同秒数据。生产方案通常改用“时间戳 主键 ID”组成复合游标例如publishedAt_from_currentItem_id。早期可以先接受时间游标但要意识到这个边界。5.4 搜索与标签页早期使用 PostgreSQL 全文检索时先给 startup 表增加一个生成列ALTER TABLE startup ADD COLUMN search_doc tsvector GENERATED ALWAYS AS ( setweight(to_tsvector(simple, coalesce(name, )), A) || setweight(to_tsvector(simple, coalesce(tagline, )), B) || setweight(to_tsvector(simple, coalesce(description, )), C) ) STORED; CREATE INDEX startup_search_idx ON startup USING GIN (search_doc);搜索接口的核心查询Query(value SELECT id, name, tagline, stage FROM startup WHERE search_doc websearch_to_tsquery(simple, :keyword) ORDER BY ts_rank(search_doc, websearch_to_tsquery(simple, :keyword)) DESC LIMIT :limit , nativeQuery true) ListStartupSearchResult search(Param(keyword) String keyword, Param(limit) int limit);setweight的作用是给不同字段设置不同优先级。名称命中比描述命中更重要所以在排序时权重更高。首次查询注意用websearch_to_tsquery而不是to_tsquery因为websearch_to_tsquery对普通用户输入更友好能容忍引号、空格等特殊字符。标签页不需要搜索索引直接按 startup_tag 和 tag 两表 join 即可SELECT s.id, s.name, s.tagline FROM startup s JOIN startup_tag st ON st.startup_id s.id WHERE st.tag_id :tagId ORDER BY s.updated_at DESC LIMIT 20;为了让标签页持续呈现“活项目”这里按 updated_at 排序而不是 created_at。一个三天前发布但持续更新的项目应该排在三个月前发布但从未更新的项目前面。这个排序逻辑才是“发布日之后继续被发现”在产品里的直接体现。5.5 每周摘要邮件的生成每周摘要用定时任务生成。任务分三步筛选最近 7 天有更新的项目按标签分组生成 HTML 邮件并发送。Component public class DigestScheduler { private final DigestService digestService; private final MailService mailService; Scheduled(cron 0 0 9 * * MON) public void sendWeeklyDigest() { ListDigestItem items digestService.findLastWeekActiveStartups(); MapString, ListDigestItem grouped items.stream() .collect(Collectors.groupingBy(DigestItem::tagName)); ListMember subscribers digestService.findSubscribers(); for (Member subscriber : subscribers) { String html renderDigest(grouped, subscriber); mailService.send(subscriber.getEmail(), 本周值得关注的创始人项目, html); } } }定时任务里最容易出的问题是在大数据量下逐个用户发送邮件导致任务积压。生产环境要改成两步先生成待发送任务写入 teamwork 队列再由发送线程或外部任务平台消费。学习环境先把单线程跑通即可。6. 本地运行和验证6.1 环境准备建议本地环境如下组件版本要求用途JDK17 以上运行 Spring Boot 应用Maven3.8 以上依赖管理Docker20.10 以上启动 PostgreSQL 和 RedisPostgreSQL16主数据库Redis7缓存和简单限流如果机器已经装了 PostgreSQL也可以直接用本机数据库。下面的步骤以 Docker Compose 为例便于一条命令恢复环境。6.2 启动依赖服务在项目根目录创建docker-compose.ymlversion: 3.8 services: postgres: image: postgres:16 environment: POSTGRES_DB: launchup POSTGRES_USER: launchup POSTGRES_PASSWORD: launchup ports: - 5432:5432 volumes: - pgdata:/var/lib/postgresql/data redis: image: redis:7 ports: - 6379:6379 volumes: pgdata:执行启动命令docker compose up -d验证 PostgreSQL 和 Redis 是否就绪docker compose ps看到两个服务的状态都为 running 后接着配置应用。在application.yml中连接数据库和 Redisspring: datasource: url: jdbc:postgresql://localhost:5432/launchup username: launchup password: launchup jpa: hibernate: ddl-auto: none show-sql: false data: redis: host: localhost port: 6379这里把ddl-auto设为none。生产或学习环境都不建议用 Hibernate 自动建表表结构应该由初始化 SQL 或 Flyway 之类的迁移工具管理。6.3 启动应用并用 curl 验证启动后端./mvnw spring-boot:run应用默认在 8080 端口启动。先创建一个项目curl -X POST http://localhost:8080/api/startups \ -H Content-Type: application/json \ -d { name: LaunchUp, tagline: 让创始人在发布日之后持续被发现的社区, description: 帮助创始人建立档案、发布更新、进入推荐池的社区平台, stage: MVP, tagIds: [1, 2] }预期返回类似结构{ id: 1, name: LaunchUp, tagline: 让创始人在发布日之后持续被发现的社区, stage: MVP, createdAt: 2025-01-01T10:00:00Z }再发布一条更新curl -X POST http://localhost:8080/api/startups/1/updates \ -H Content-Type: application/json \ -d { title: LaunchUp 第一版社区 Feed 完成, content: 用户现在可以关注项目并接收最新动态, updateType: MILESTONE }请求首页 Feedcurl http://localhost:8080/api/feed?memberId1limit20如果没有数据先检查成员是否关注了项目。Feed 只返回“已关注项目”的动态这一点在验证时最容易混淆。6.4 预期输出和检查点接口正常结果常见异常POST /api/startups返回新项目对象id 自增参数校验失败返回 400POST /api/startups/1/updates返回更新对象并写入活动表项目不存在返回 404GET /api/feed返回已关注项目的动态列表未关注任何项目时返回空列表GET /api/search?keywordLaunchUp返回名称命中结果无匹配时返回空数组到这里最小闭环已经跑通创建项目、发布更新、订阅关注、Feed 输出、搜索命中。这五个动作覆盖了“发布日之后被持续发现”的核心链路。6.5 学习环境与生产环境的区别本地跑通不代表可以上线。下表是一次明显的能力分界维度学习环境生产环境数据库迁移手动执行 SQLFlyway / Liquibase 版本化错误响应返回默认错误页面统一错误码和日志追踪 ID图片存储本地目录对象存储加 CDN定时任务单机 Scheduler分布式调度加幂等控制搜索PostgreSQL 全文检索视数据量决定是否引入独立搜索引擎垃圾内容不做处理需要审核队列、举报、封禁机制监控无日志、指标、告警、慢查询分析如果直接拿学习环境的工程结构上生产第一批用户进来后就会遇到图片无法访问、邮件任务超时、垃圾内容刷屏、数据库连接池被慢查询打满等问题。7. 常见问题与排查路径7.1 Feed 出现重复或丢失动态现象用户关注多个项目后翻页时看到重复动态或者某个项目的更新没出现在 Feed 里。可能原因分页使用 OFFSET新数据插入后页边界移动。“关注项目列表”为空但前端仍然发起了分页请求。更新写入时没有同步写入 startup_activity导致 Feed 和趋势页数据不一致。排查方式查看关联查询 SQL确认启动项目列表是否包含对应 startup_id。检查 update_post 和 startup_activity 两个表同一时间点的新增记录数是否一致。在翻页请求中打印 cursor观察下一轮请求是否使用了正确游标。修复方式全面改用游标分页发布更新的写路径需要事务保证两表同时写入如果历史数据已经不一致就写一个对账脚本以 update_post 为准补写缺失的事件。7.2 时区导致更新时间错位现象项目明明在本地时间 23 点发布了更新第二天发现摘要邮件里没有这条动态。可能原因数据库存储使用timestamp without time zone应用服务器和数据库服务器时区不一致。定时任务使用服务器本地时间计算“最近 7 天”而服务器时区不是目标用户时区。前端渲染时间直接把 UTC 时间转为字符串导致展示偏移。排查方式执行show timezone;查看 PostgreSQL 时区。用SELECT published_at AT TIME ZONE UTC FROM update_post;对比。查看应用日志中定时任务的触发时间和实际执行时间。修复方式所有时间字段统一使用TIMESTAMPTZ定时任务使用固定时区比如Asia/Shanghai计算窗口前端使用 ISO 8601 格式传输时间由浏览器本地渲染。这样能避免服务器时区漂移影响业务判断。7.3 搜索索引与业务数据不一致现象新创建的项目在数据库里查得到但搜索接口返回不了。可能原因使用独立搜索引擎时没有建立同步任务或同步任务失败。使用 PostgreSQL 生成列时旧数据没有回填。关键词输入包含引号、标点全文检索函数解析失败。排查方式查询项目是否存在SELECT * FROM startup WHERE id 1;检查搜索索引文档是否更新SELECT id, search_doc FROM startup WHERE id 1;直接执行搜索 SQL 看是否有语法错误。修复方式首次上线先做全量索引任务新数据通过事务内同步或异步消息补偿。如果生成列已经建立但旧数据为空执行一次REINDEX或手动更新即可。对普通用户贡献的搜索词进行处理时优先使用websearch_to_tsquery而不是裸to_tsquery。7.4 N1 查询导致 Feed 变慢现象Feed 接口在只有 100 条动态时就消耗 300ms 以上数据量增长后越来越慢。可能原因循环查询每个 startup 的详情。循环查询每个 update_post 的作者和项目。在循环里多次访问缓存。排查方式打开 Hibernate 的 SQL 日志统计一次 Feed 请求实际执行的 SQL 条数。用EXPLAIN ANALYZE检查核心查询是否命中了(startup_id, published_at DESC)索引。修复方式关联数据一次性查出比如 Feed 查询结果出来后用IN批量查项目和作者把项目名称、Logo 等高频字段放入缓存或者直接在 startup_activity 的 payload 里冗余一份标题、项目名减少回表。7.5 深翻页导致接口超时现象用户翻到第 50 页之后接口响应明显变慢甚至超时。可能原因还是用了 OFFSET 翻页数据库扫描了大量已读行。排序字段没有索引或索引顺序不正确。查询条件缺少 startupIds 边界导致全表扫描。排查方式看慢查询日志确认 SQL 的 rows 扫描数和返回数差异。用EXPLAIN查看索引是否被使用。修复方式全站统一使用游标分页确认published_at和startup_id的复合索引方向对 Feed 和搜索接口设置最长分页深度超过深度的请求直接返回空数据并引导用户使用筛选条件。7.6 常见问题速查表问题现象常见原因检查方式处理建议发布更新后 Feed 不出现写入未提交或活动表未同步查看数据库日志和 startup_activity统一事务补写事件翻页出现重复动态使用 OFFSET 分页打印分页参数和结果 ID改游标分页搜索找不到新项目索引没同步比较数据库和索引数据量补全量索引任务首页加载慢N1 查询开启 SQL 日志统计条数批量查询加缓存摘要邮件缺少某项目时间窗口算错检查定时任务时区统一 TIMESTAMPTZ 和固定时区热门列表被老项目霸榜排序只看历史流量检查 score 计算日志引入近期更新和活跃加权8. 最佳实践与扩展方向8.1 把“持续发现”做成产品机制而不是页面字段很多团队会把“发布日之后继续被发现”理解为在项目页加一个“最新动态”栏。这对但远远不够。真正的持续发现要建立在三条产品机制上有周期性触达每周摘要、通知、专题页。有可检索入口标签、搜索、赛道目录。有活跃度信号项目更新会重新进入 Feed 和搜索排序。工程实现上这三条机制的共同基础设施就是事件表加活动流。只要所有业务动作都写入 startup_activity后续加通知、加推荐、加数据报表都只是对事件表的查询和组织。8.2 内容治理和反垃圾创始人社区比普通 UGC 平台更容易被广告号、招聘号、营销号盯上。上线前至少要有创建项目和发布更新前做登录校验。对 URL、联系方式等敏感内容做正则或关键词过滤。设置发布频率限制防止单用户短时间内刷屏。运营后台支持标记、隐藏、删除项目。对搜索接口做限流避免被爬虫拖垮。学习环境可以不实现这些但它们应该被写进系统设计文档保证后续迭代时不会被遗忘。8.3 关键指标“发布日之后有没有被持续发现”不能只靠感觉。建议上线后第一周就埋好以下指标指标计算口径说明发布后 30 天回访率发布后 30 天内再次访问项目页的用户数 / 发布日访问用户数衡量内容后续吸引能力活跃项目占比最近 30 天有更新的项目数 / 全部上架项目数衡量平台生命力标签页点击率标签页点击次数 / 标签页展示次数衡量目录式发现是否有效摘要邮件打开率打开邮件用户数 / 发送邮件用户数衡量周期性触达质量Feed 平均卡顿时间用户从打开 Feed 到看到首条动态的耗时衡量接口性能这些指标不需要一开始就做成完整数据平台先通过日志和定时统计记到一张 daily_metric 表里即可。但字段口径要在第一版就固定否则后期换口径无法横向对比。8.4 上线前检查清单数据库迁移脚本是否有版本控制。所有外键和时间字段是否统一使用建议类型。Feed 分页是否使用游标。发布更新和活动写入是否在同一事务内。搜索索引是否支持全量初始化。图片是否走对象存储而不是本地磁盘。邮件发送是否有失败重试机制。定时任务是否具备幂等性。是否有内容审核和举报入口。是否有基本监控和错误日志追踪。8.5 扩展方向第一版跑通后可以从以下方向扩展个性化推荐基于用户关注标签和浏览历史对 Feed 做重排序。社区讨论允许用户在项目下发起问答和评论把项目页变成对话场所。创始人访谈和专题由运营制作深度内容将分散项目串成主题故事。数据图谱展示创始人历史项目、投资关系、合作伙伴形成更丰富的身份档案。开放接口让第三方工具可以通过 API 查询项目状态和更新记录。扩展时最需要守住的底线是不要破坏“项目为中心”的信息模型。一旦把关注重心从项目转移到泛社交关系系统就会偏离最初要解决的“发布日之后持续被发现”的问题。如果把整个系统抽象成一句话不要把创始人的价值压缩在发布日那一天而是让平台能够回答“这个创始人最近在做什么、解决什么问题、值不值得关注”。工程上的任务就是让这三个问题变得可检索、可订阅、可量化。LaunchUp 这类社区能否真正胜出不取决于发布页做得有多炫而取决于发布后 30 天、90 天用户能不能持续在这里重新遇见一个有进展、有观点、有行动力的创始人。