核心项目 2 分钟讲稿

这份文档给你两段可直接拿去讲的项目稿：

海外业务平台
推广 / ROI 平台

目标不是写成“项目介绍”，而是写成你在面试里真的能说出口的话。

一、海外业务平台 2 分钟讲稿

如果让我讲一个最能代表我最近几年能力的项目，我会讲海外业务平台。这条线表面上看是 AI 识别相关，但从后端角度看，它其实是一个完整的海外垂直产品后端系统，不只是识别接口，还包括收藏、真人鉴定、订阅、支付、退款、交易、归因、SEO 和后台运营支撑。

我在这条线里重点负责的是几块核心链路。第一块是订阅和支付相关，包括 iOS / Android 的订阅购买、Apple 和 Google 的回调处理、退款、恢复订阅和权益同步。第二块是真人鉴定和相关业务流转，比如鉴定订单、鉴定师分配、语音转文本、翻译和审核。第三块是归因和报表，包括 Google Ads、ASA、TikTok、分享和 H5 链路的数据记录与报表支撑。除此之外，我也做过导入、搜索、SEO、OpenAI / Dify 工作流这类配套能力。

这条线最难的地方不是接第三方，而是状态和链路很长。比如支付成功、退款、恢复订阅、赠送真人鉴定次数、用户登录同步权益，这些都可能同时影响同一个用户的可用权益。如果状态模型没统一好，后面线上会非常难查。所以我在这里面做得比较多的是先把主状态和派生状态拆清楚，再通过幂等、补偿任务、关键日志和缓存把链路做稳。

技术上这条线主要还是以 PHP 为主，因为业务规则复杂、变化快，而且和客户端、产品、运营协作很密集；MySQL 承接交易和状态数据，Redis 做缓存和幂等，ES 承担搜索和导入，外部会接 Apple、Google、Stripe、PayPal、Google Ads、ASA、AppsFlyer 这些能力。对我来说，这个项目最能体现我的地方，不是我接过多少平台，而是我能把 AI 能力、交易链路、增长归因和后台能力一起落成一个真实可运行的系统。

这一段讲完后，如果对方追问，你可以往下接的点

订阅 / 支付 / 退款状态一致性怎么处理
真人鉴定为什么是典型多阶段业务流
为什么这条线主战场是 PHP
归因报表和交易链路为什么会互相影响

二、推广 / ROI 平台 2 分钟讲稿

如果讲 Go、高并发和数据链路这块，我最适合讲的是推广和 ROI 平台。这个项目不是简单的广告平台对接，而是一整套广告增长和数据回传系统，里面会涉及原始曝光点击数据、激活归因、注册登录支付等行为回传、LTV 回传、广告管理后台、优化助手和报表分析。

我在这条线里做的事情分两部分。一部分是 PHP 侧的后台和规则配置，比如广告账户、计划、规则、回传配置、后台管理这类复杂业务逻辑。另一部分是 Go 侧的实时链路和高并发服务，比如点击数据处理、激活归因、行为回传、Kafka 消费和部分批量处理、长链路任务。

这条线真正复杂的地方，不在于接一个广告接口，而在于它是一条很长的数据链路，而且不同平台规则差异很大。我们在技术上做了明确分层：MySQL 放业务主数据和配置；MongoDB 承接原始曝光点击和行为事件，因为这类数据写入频率高、结构相对灵活；Kafka 做异步解耦，把实时链路从主流程中拆开；ClickHouse 承担报表和分析查询，因为优化助手、广告列表、ROI 报表这类场景不适合长期压在 MySQL 上；Go 负责消费者、实时处理和高并发服务，PHP 继续承接后台和规则逻辑。

这条线里我印象比较深的问题，一个是原始点击数据丢失，一个是回传异常和配置错误导致链路跑偏，还有一个是报表容易对不齐。我的处理方式不是只盯某一段代码，而是按链路分层看问题：原始事件有没有接住，Kafka 有没有堆积，消费者有没有异常，回传规则是不是有问题，报表层是不是该补重算和校验。最后再通过幂等、重试、关键日志和告警把它做成可追踪、可重放、可修正的系统。对我来说，这个项目最能体现的不是我用过多少中间件，而是我能把一条高并发数据链路真正治理起来。

这一段讲完后，如果对方追问，你可以往下接的点

为什么 MongoDB 放原始事件，不用 MySQL
为什么 ClickHouse 更适合报表
为什么这条线要把部分能力拆到 Go
Kafka 如何解决高峰期吞吐和链路解耦

三、你现场怎么用这两段

如果面试官说“挑一个你最熟的项目讲讲”

优先讲：

技术总监 / 解决方案面：海外业务平台
Go / 高并发 / 数据链路方向：推广 / ROI 平台

如果面试官说“再讲一个不同类型的项目”

用另一条线补上：

先讲海外，再讲推广
或者先讲推广，再补海外

最稳的收尾句

你每次讲完都可以收一句：

这个项目对我最大的提升，不是我会了某个技术，而是我更清楚复杂业务和长链路系统该怎么拆、怎么落、怎么做稳。