技术专家🧑‍💻

为啥写？源于 看到一个专栏，讲中台，简单唠几句。 “技术中台”与“后台”虽然在实际业务中有交集，但定位、目标、服务对象和使用方式存在明显差异。下面是主流理解下的核心差异对比： 🚧 简单区分： 后台（后

🧠 一、数据权限问题的典型场景 场景 示例 按部门隔离 只能看到自己部门创建的数据 按角色控制 主管能审批，普通员工只能查看 按字段限制 财务字段只能财务角色可见 动态条件限制 只能看“自己创建”或“

🧠 一、什么是审批流系统？ 审批流系统是一种状态驱动 + 多角色协同 + 条件分支控制的业务流程系统： 提交 → 审批中 → 审批通过/驳回 支持节点签字、多人会签、加签、抄送、跳过等复杂操作 要求支

🧠 一、日志采集的核心难点 量大：字节跳动级别每天产生数百 TB 日志 链路长：从客户端 → 采集器 → 聚合服务 → 下游消费（Hive、ES） 实时性要求高：部分日志需秒级进入实时推荐系统 多格式

🧠 一、为什么要构建多级缓存？ 性能需求：数据库查询慢，访问延迟高 成本控制：热点数据频繁访问，数据库成本高 可用性保障：即使后端宕机，也能提供服务 字节典型多级缓存结构： 🏗️ 二、字节跳动的缓存体

🧠 一、服务注册中心是什么？ 在微服务架构中，服务注册中心承担如下职责： 服务实例上线 → 注册 服务心跳 → 保活 实例异常 → 自动摘除 客户端调用 → 服务发现 + 负载均衡 🔁 典型架构图：

🧭 一、Feed 流的推荐流程是什么？ Feed 流排序通常分为以下五个阶段： 召回（Recall） ：根据兴趣/社交/热度快速筛出 10w+ 初筛（Pre-filter） ：剔除低质内容、黑名单、频

🔍 一、推荐系统的三大阶段 推荐系统一般分为三个阶段： 召回（Recall） ：从海量内容中筛出候选集合（10w → 1k） 粗排（Rough Rank） ：对候选内容进行初步打分排序（1k → 30

一、前言：图表≠可视化系统 广告平台的数据大屏最初是“页面堆图表”： 逻辑重复、样式不一致 图表配置散落页面中 接口调用、loading 控制混乱 我主导将其重构为：组件可复用 + 数据逻辑统一 +

一、背景：组件“够用”≠“好用”，更不是“可扩展” 广告平台最早使用的是 Naive UI + 本地封装组件，但存在以下问题： 同类表单页面重复堆砌，体验不统一 页面间字段格式/布局风格差异大 样式、

一、背景：当项目越来越大，单体架构变成技术负担 广告平台经历多个阶段： 初期为单 SPA（Single Page Application），业务快速集中开发 中期模块增多、接口冲突、构建缓慢、协作困难

一、前言：当项目越来越大，路由系统就成了“协作痛点” 广告平台发展初期，所有模块路由写在一个 routes.ts 中： 多达上百条路由，查找困难 权限判断逻辑散落在各个页面 多角色用户共享代码，但显示

一、前言：接口混乱，是大型前端系统的最大隐患 广告平台项目中，前期接口调用写法五花八门： 直接在组件里 axios.post 缺乏统一 loading、报错提示、缓存策略 同一个接口被不同模块重复封装

一、起点：从"能用"到"难维护" 初期的广告投放平台是 MVP 快速上线版本，存在大量技术债： 组件无抽象，页面全靠复制粘贴 接口管理混乱，重复请求冗余严重 表格、表单、弹窗、权限等逻辑硬编码在业务中

一、背景：上传功能不是“传上去就完事” 广告平台对上传素材要求高： 支持图片 / 视频 / ZIP（动画包）/ JSON 等格式 支持结构校验（如 ZIP 内必须包含特定文件） 分平台上传（管理后台、

一、项目背景 广告平台的核心指标（曝光量、点击率、转化等）需要实时展示给广告主与运营人员。 我们设计了一个“可定制 + 高性能 + 多图层渲染”的数据大屏，支持： 多模块折线图/柱状图/饼图 实时数据

一、问题背景：权限系统做得好，项目少一半 bug 广告平台的典型权限场景： 多角色（广告主、运营、审核员、管理员） 页面权限 + 按钮权限 + 接口权限 + 数据权限 权限频繁变更，要求灵活配置 +

一、背景：为什么表单最难维护？ 在广告平台中，表单遍布各个业务模块：新建广告、编辑素材、审批流表单、充值申请、内容提交…… 问题在于： 字段多达几十个，表单嵌套层级深 联动逻辑复杂，部分字段按角色/状

一、前言：AI 正在重构整个前端行业 大模型并不是“取代前端”，但它正在改变前端工作的方式： 代码生成正在成为主流习惯 页面构建开始模板化 + 语义驱动 低代码与 DSL 日益融合大模型生态 作为一个

一、背景：前端协作最大的问题是“重复 +不一致” 在广告投放平台项目中，我团队经常遇到这些协作问题： 新同事无法快速理解老代码结构 代码注释随时间变得“形同虚设” Review 耗时、标准不一、易放过