导读：「以客户为核心，技术为产品服务」是爱番番线索管家团队一贯遵循的准则。技术架构布局首先应该围绕业务诉求开展，用正当的技术赋能产品，产品在一直的演进中又对技术提出更高的规范和要求。作为爱番番 PV 最高的页面，本文将具体介绍线索列表如何从疾速交付的刀耕火种原始状态，逐渐走向“高可用、高质量、高体验“的成熟期。

全文 9355 字，预计浏览工夫 24 分钟。

在后盾零碎中，列表是最常见的数据展现形式之一，它就像零碎的水电煤一样平时，以至于你可能会问列表开发能有什么技术挑战呢？

一、列表应该提供什么能力？

列表页有三个根本模块：

1. 搜寻
2. 搜寻框（定向查找某条数据）
3. 筛选项（预置搜寻条件疾速找到符合条件的后果）
4. 数据出现
5. 表头
6. 数据
7. 分页器
8. 操作项
9. 操作按钮（对整行数据），比方线索列表的调配、打电话
10. 批改数据（对某个字段），比方增加标签

列表承载着业务上的数据，列表的设计体验关乎用户对业务数据的解决和管理效率，最终的指标是为了能进步客户应用数据及决策的效率。

二、技术落地演进

随着爱番番产品的疾速迭代与演进，线索列表也从疾速交付的刀耕火种原始状态，逐渐走向“高可用、高质量、高体验”的成熟期。上面将逐个介绍线索列表经验过的不同版本，踩过的坑以及相应的解决方案。

V1 – 疾速落地根底能力

爱番番我的项目初期，为保障我的项目疾速落地，帮忙用户及时疾速查问和跟进线索，线索信息寄存到 MySQL，提供根底的 CRUD 能力。

V2 – 配置扩大能力

随着业务一直演进，根底的表单及列表性能与用户可配置、可扩大需要之间的矛盾愈发突出，如何反对自定义能力，是线索列表面临的一大难题。爱番番线索管家团队次要从「元数据驱动」，「指标解析器」，「前端渲染引擎」三方面着手解决。

2.1 元数据驱动

随同线索产品一直迭代，线索预置字段数量一直减少。并且线索降级能力反对自定义字段，原来页面固定的检索项已不能满足用户对所有线索字段进行检索的需要，所以咱们提出了通过自定义检索项元数据动静实现检索项的渲染，以满足用户的集体偏好。

1、UI 渲染信息实现检索项在页面动静渲染

2、检索条件构建器，动静构建检索项指标数据

3、检索项操作符反对不同指标的检索范畴

4、检索项关系符能够动静组装检索条件的查问场景

5、当有新的筛选指标须要增加时，只须要增加检索项元数据和实现检索项的构建器

2.2 指标解析器

随着线索字段的一直减少，在列表中须要实现表头的灵便配置，和列表项的疾速加载，提炼了自定义列表指标项元数据。

1、自定义列表

在列表检索的这个服务中，通过接入通用自定义指标服务来实现用户自定义列表项的灵便配置。

2、指标检索配置化

通过引入检索指标的概念，能够将列表字段的查问形象为对指标的查问。这样的话不同的查问场景即可建模为对不同指标数据的查问，指标数据之间能够任意组合以满足需要。此时底层只须要提供一个通用的指标检索服务即可。

3、后置处理器

对于不同的场景，列表字段须要不同的展示模式；通过引入后置处理器，能够通过配置化的形式定制渲染逻辑。新指标只需在配置对应的指标元数据即可。

2.3 前端配置化引擎设计

最后线索列表和筛选项仅反对较少字段展现和筛查，因而咱们只须要对特定字段进行非凡解决 UI 组件进行渲染即可。但随着业务复杂度减少、字段增多以及自定义字段的退出，单纯针对特定字段进行非凡解决进行渲染带来了微小保护老本（减少字段须要为此字段独自开发 UI 组件，需一直调整相干业务代码）和测试回归老本，且无奈满足自定义字段的筛选及展现。于是引入配置化引擎设计，以组件为根本单位，通过组件参数配置实现页面相干内容渲染。

1. 每个组件均是由元数据驱动的标准化组件，分为组件和配置两局部；

2. 将后端返回的组件配置信息和本地默认配置 merge 后生成最终配置；

3. 组件配置引擎通过解析组件配置，动态化的绑定事件、传递数据、渲染组件；

引入配置化引擎设计后，前端只有在新增组件类型时才须要投入开发人力，对于其余同质化需要仅需后端批改配置即可失效，极大升高了开发和测试回归老本。

V3 – 降级体验

3.1 背景

线索列表是线索管家的外围业务场景，随着业务的一直倒退，急需对线索列表的体验进行降级。

3.2 设计指标

秉持信息易懂、体验易用的设计价值观，通过对列表信息进行重组和体验降级，从而晋升线索列表客户满意度。

3.3 设计打法

3.3.1 页面拆解

线索列表页由题目、工具栏、表格三大模块形成；

1. 题目区：包含题目、规定阐明等信息，概括整个页面的信息；
2. 工具栏区：包含数据过滤（筛选、搜寻）、性能操作（新建、导入 …)，承载页面的增、删、改、查等操作；
3. 表格区：包含表头、表体、分页，展示页面的外围信息。

3.3.2 外围痛点

1. 题目区：规定不明确，了解老本高；
2. 工具栏区：数据过滤及性能操作密度大，烦扰信息繁冗；
3. 表格区：外围信息展现屏效比低，操作老本高。

3.3.3 设计策略

1. 题目区降级

• 【题目区】规定阐明由图标优化为图标 + 文字模式，直观易懂；

2. 工具栏区降级

• 【性能操作】外露重要高频操作，折叠低频操作，升高对用户的烦扰；
• 【数据过滤】外露高频筛选，折叠低频筛选，晋升外围表格区屏效占比；

3. 表格区降级

• 【表头】页面上滑，表头吸顶展现，易于定位字段信息，拓展线索列表纵向空间；
• 【表体】页面横滑，横向滚动条悬浮于屏幕底部，晋升横向操作效率；
• 【表体】操作列采纳主次模式，外露高频性能，折叠低频性能，无效晋升操作效率和性能扩大空间。

▲线索列表降级前后比照图

3.4 设计收益

通过形成、交互、反馈、适配四个维度将页面信息进行深挖与重组，外围表格区屏占比达到 70%，数据展现更正当，晋升线索列表页面易用性与客户满意度。

V4 – 降级检索能力

4.1 现状和挑战

目前零碎线索预置字段 58 个，动静扩大字段 125 个以及亿级线索数据。业务一直降级所有线索字段纳入自定义检索（多条件检索，分词检索等）和日益收缩的数据让检索的性能面临挑战，咱们应用 ES 代替 MySQL 来实现高性能的高级检索性能。

4.2 方案设计

名词解释 -WATT：百度数据流开放平台 - 瓦特（WATT）, 是数据流自助开发和运维平台。数据流捕捉 mysql 数据库中变动数据实时公布进去，以增量和基准两种形式进行公布，提供文本格式数据，保障实时性、数据的有序和不丢，还能够对订阅数据进行计算。

计划：检索由 DB 迁徙到百度云 ES 服务，用户操作完线索后数据更新到 DB，再通过 WATT、MQ 和写入服务将数据同步到 ES。

收益：进步查问效率，反对全文分词场景，数据进行相关度排序等，反对任意检索条件组合查问不影响查问性能。

V5 – 反对写后读(Read your writes)

5.1 现状和挑战

线索列表检索由 MySql 迁徙到 ES 后，又带来了新的问题，DB 在同步 ES 的过程中，容易受依赖环境影响导致数据更新有提早，导致用户在线索列表看到的不是最新数据，对用户体验有肯定的影响，从而对线索列表的稳定性和准确性带来了新的挑战。

数据流现状如下：

上述中 DB 同步 ES 共须要 5 步，任何一步呈现提早都会造成线索列表数据更新不及时。

5.2 优化指标

即便 DB 到 ES 数据同步存在延时，也能保障线索列表中的数据与用户操作后的后果统一。

5.3 方案设计

1、用户对线索进行操作 (新建，调配，编辑等) 后， 将操作后的线索 ID 写入到 redis 有序队列中，因为 DB 同步到 ES 延迟时间大略在 0～2s 间，因而 redis 队列主动过期策略设置为 10s。

2、redis 队列只写入线索 ID，而不是存储残缺的线索数据快照:

a、线索属性多、构造复、迭代变动快，只记录线索 ID 比拟轻量级，线索自身变更不影响 redis 中缓存的数据结构；
b、查问时依据 ID 从 DB 中查问，数据更精确，因为没有事务去保障 redis 与 DB 中的数据强一致性。

3、用户查问线索列表数据

a、获取 redis 有序队列中最近 5s 的线索 ID

b、组装 ES 筛选条件查问 ES 数据，获取 redis 线索 ID 筛选 DB 数据，为了保障列表的查问性能，采纳并发查问

c、通过表达式引擎，依据 ES 筛选条件过滤 DB 线索数据，获取无效的查问后果

d、通过 merge 策略实现 ES 数据和 DB 数据 merge

merge 策略

为了可能简略论述 merge 的各个场景，咱们先定义一下几个对象

1、leads\_es：线索对应的 ES 后果视图
2、leads\_db：线索对应的数据库视图
3、result\_es = {….}：ES 查问后果的后果集
4、result\_redis\_db = {….}：通过 redis 获取线索 ID 查问 DB 的后果集
5、result\_redis\_db\_filter = {…}：result\_redis\_db 依据筛选条件通过表达式引擎过滤后的后果集
6、candidate = {….}：最终交融到的后果集咱们称之为候选后果集

candidate 抉择策略

1、有新增或批改操作后的线索且满足过滤条件的，应该把 DB 中查问到的线索退出候选集

2、没有操作过的线索且满足过滤条件的，应该把 ES 中查问到的线索退出候选集

3、操作过的线索且不满足过滤条件的，不应该退出候选集

成果收益：上线后无用户在反馈操作线索后列表数据提早类问题，线索打标签后首次查得率、编辑线索后首次查得率均为 100%。

V6 – 性能优化

6.1 如何度量性能

If you can’t measure it, you can’t improve it!

页面性能度量是优化的前提，而前端性能监控也是一个经久不衰的话题。监控方向、监控指标、埋点计划、上报工具都是须要思考的点，业界商用打点平台及厂内埋点平台，均无奈解决易用、实时、前后端全链路监控等问题。为此爱番番启动「大前端 APM」专项，参考服务端 RED 指标及业界支流前端埋点计划，摸索最适宜爱番番的前端 APM 体系架构。

6.1.1 监控指标

从全局问题登程，可能洞察统计性的页面 url 实在性能指标，以及能够做操作流任意阶段之间的统计性耗时剖析。

从个案问题登程，可能基于用户 id 进行任意一次全端调用链追踪。

6.1.2 解决方案

采集

埋点 SDK：爱番番业务打点应用付费零碎「神策」，为防止反复造轮子，前端 APM SDK 基于神策 SDK 进行二次封装，通过 npm 包模式进行版本治理；应用方在公共模块对埋点 SDK 进行初始化。减少无侵入性能采集能力，提供采样率等配置扩大能力。

上报

综合 image、sendBeacon、Ajax 上报计划。首先拼接携带参数的残缺的 url，判断 url 的长度，如果 url 的长度小于浏览器容许的最大长度内，则通过动态创建 img 标签的模式来发送前端性能数据；

若 url 太长，则判断浏览器是否反对 sendBeacon 办法，如反对则通过 sendBeacon 办法来发送申请，否则发送同步的 ajax 申请。示例代码如下：

function dealWithUrl(url,appId){let times = performanceInfo(appId);let items = decoupling(times);let urlLength = (url + (url.indexOf('?') < 0 ? '?' : '&') + items.join('&')).length;if(urlLength<2083){imgReport(url,times);// 示例办法  }else if(navigator.sendBeacon){sendBeacon(url,times);  }else{ajaxReport(url,times);// 示例办法  }}

前后端 Trace 买通

### 6.2 性能问题 & 指标

问题 ：前端 APM 在 2021 年 Q2 全面落地，使得爱番番前端性能监控迈出一大步。但同时暴露出不少页面性能较差、大数据量用户可感知时长较长等问题。 其中线索列表性能问题尤为突出，页面初始化用户可感知时长超过 5000ms（P90）；

指标：通过对爱番番所有页面性能统计分析，前端整体性能指标为「页面初始化用户可感知时长低于 2000ms（P90）」，分段拆解指标如下：

### 6.3 优化思路 & 计划

整体优化思路及节奏：先抓主要矛盾，摘高扬果实；再抠细节，进行难点攻坚。每个方向均做到极致，各个击破。

• 【链路】厘清页面残缺链路及耗时，全面理解页面性能现状。
• 【后端】深入分析后端代码实现逻辑，从并发、缓存、es 调优、线程池调优，依赖超时剖析等方面着手优化接口性能。
• 【前端】剖析前端代码、编译配置、浏览器 Performance 火焰图，从动态资源体积、JS Runtime Long Task、渲染性能等方面动手优化前端性能。
• 【交互】与产品、设计独特探讨交互降级计划，以达到极致用户体验。

#### 6.3.1 耗时链路剖析

名词解释：BFE，Baidu Front End，百度对立前端，是百度对立的七层 (HTTP/HTTPS) 流量接入平台；为整个百度提供流量接入服务。

用户可感知耗时链路：

1. 从 CDN 节点加载动态资源（动态资源耗时）
2. 执行 js 文件，发送 Ajax 申请（接口总耗时开始）
3. 浏览器收回 Http 申请，到达 BFE 的网络耗时
4. BFE 转发至 Access Gateway 链路耗时
5. Access Gateway 转发至 BFF 服务链路耗时
6. BFF 本身服务耗时（蕴含服务外部申请、拼装微服务等），由 Skywalking 统计
7. BFF 返回 response，至 Access Gateway 链路耗时
8. Access Gateway 返回 response，至 BFE 链路耗时
9. BFE 返回 response 到浏览器网络耗时
10. 浏览器渲染耗时

问题：

• BFF Node.js 服务调用后端微服务链路耗时长。
• BFF 通过域名 -BFE- 微服务形式调用时，BFE 局部 VIP 存在连贯超时问题无奈彻底解决。

优化前 BFF 调用链：

计划：

• BFF 模块降级 Mesh 服务。BFF 调用后端服务形式，由网关域名调用，降级为 Mesh service 调用。

优化后 BFF 调用链：

收益：BFF 调用微服务链路耗时升高 100ms+，BFE VIP 连贯超时频发问题失去根治。

#### 6.3.2 接口性能优化

通过剖析接口实现逻辑以及 SkyWalking 调用链，发现上面三类问题：

第一类问题：代码实现问题。属于高扬的果实比拟容易摘到。

问题：

• BFF 及后端接口链路存在非必要串行申请
• 前后端均存在能够应用缓存场景

计划：

• 在 BFF 实现层面，将三次串行申请，优化成必要的两次串行，其余均应用 Promise.all 并行处理
• 对服务端接口后置处理器，对立应用线程池异步解决
• 对标签元数据、表头配置元数据等接口减少 Redis 缓存
• 前端对权限、查问条件等接口进行预加载，并减少本地缓存

第二类问题：性能调优。这部分须要理解 ES、RPC 框架底层实现原理。

问题：

• 应用 ES 检索含糊查问性能较差
• 线索服务压测不达标，高 QPS 下申请排队

计划：

• 应用全文检索来代替含糊查问
• 调整 RPC 调用 RPCIoWorkThreadNumber 工作线程数

第三类问题：超时问题。这部分优化场景简单，难度较高。超时问题有几类：

问题：

• RPC 调用连贯超时：老版本 Mesh sdk 每次发动申请时会从新创立新的连贯，导致调用方在并发大或者拜访的服务平响高时，会呈现连贯期待，以至连贯超时。
• 网关查问超时：线索所属 DB 集群 sfcrmsales 磁盘利用率较高，慢 SQL 及长事务较频繁，DB 集群稳定性不高，导致 DB 查问频发超时。
• 依赖内部服务超时：线索列表须要对线索池权限等进行鉴权操作，依赖 ACS 团队权限接口超时频繁；列表检索结束后，须要对局部字段进行加工，波及不少内部团队 HTTP 申请调用，其中大商业广告信息 open API 调用超时最为频繁。

计划：

1. 对 Mesh SDK 进行连贯复用革新，并调整服务本身 IO 线程数，解决 QPS 高的状况下连贯期待问题；

2. DB 集群稳定性治理

• 设立 DB 稳定性治理专项，减少 DB 告警、值班机制；
• 联结 DBA 对慢 SQL、长事务、连接数异样、主从提早低等问题进行彻底剖析、排查、解决、验证、根治；
• 对 DB 中重试表、调配日志表、outbox 表等大表进行清理，对线索原始信息主表进行定期数仓转储，并清理表中大字段；
• 对集群中非一级业务表进行迁库操作，加重线索 DB 集群存储压力。

3. 超时问题治理

• 调整 ACS 服务线程池大小，对 ACS 服务进行程度扩容；
• 对广告信息接口进行   缓存 + 离线数仓 + 实时调用  组合查问计划，并调整后置处理器超时工夫，保障绝大部分场景查问速度。

收益：线索列表服务端耗时（P90）从 2500ms+，缩短至 800ms 以下。

6.3.3 前端性能优化

前端性能问题次要集中在渲染卡顿和动态资源加载耗时长两方面。

第一方面：列表渲染优化

背景：

爱番番前端整体采纳 vue 技术栈，elementUI 作为 vue 生态中最受欢迎的 UI 框架，因其弱小的性能、健全的生态以及沉闷的社区，被选做爱番番前端 UI 框架。线索列表应用 element-ui 中 el-table 组件，可能反对列表场景常见需要。

问题：

1. 大数据量（100 行、50 列）状况下，JS Long Task 时长将近 3000ms，线索列表渲染卡顿。

2. 数据整体渲染工夫较长，用户期待（loading）工夫长。

3.el-table 不反对吸顶、吸底操作，单纯通过批改 CSS 款式亦无奈实现，体验不佳。

剖析：

浏览 el-table 源码发现，el-table 的实现是通过四个 HTML 原生 table（表头、表身，列表左右侧勾选列）实现。大数据量下，DOM 数量会变得异样宏大；尤其是在表头拖拽，对页面进行 Repaint 和 Reflow 时计算量微小，Long Task 较长，导致页面卡顿。

调研基于动静渲染思路的开源组件 pl-table，不反对吸顶性能，且在行高不固定的状况下反对状况不良，被排除。

计划：

1. 通过调研业界支流 UI 框架，只有 React 体系中的 AntD table 反对吸顶性能，但其 vue 版本存在滞后性并未反对该揭示。通过组内探讨，决定参考 React AntD table 实现思路，从新实现 AFF-UI table。

2. 列表数据渐进式渲染。先渲染首屏数据，完结 loading 为用户出现首屏列表。同时在用户无感知的状况渲染其余列表数据。

收益：

1.AFF UI table 相比 el-table，雷同数据量下，DOM 数量缩小 60%，100 行、60 列数据量下，渲染性能晋升 300%；

2. 反对列表吸顶吸底性能，体验晋升较大；

3. 渐进式渲染，首屏可感知渲染时长（P90）从 2000ms 升高至 500ms 以下。

第二方面：动态资源优化

背景：

爱番番前端应用自研 Tangram 微前端架构，分为主模块「common」，以及其余业务域子模块。反对各麻利小组页面分代码库，独立部署运维。前端动态资源均部署在百度云 BOS 上，通过 BFE 进行域名动态资源转发定位。

问题：

• 动态资源通过 BFE 转发，减少链路耗时
• 动态资源未应用 CDN 网络
• 动态资源体积较大

剖析：

动态资源优化思路，从链路、缓存、编译三方面动手。

链路和缓存，是前端优化常见伎俩，计划大同小异。编译的问题个别暗藏较深，须要对 webpack 编译打包原理有肯定理解。上面着重介绍下编译相干剖析过程：

1、首先通过监控平台，对 js 加载瀑布流进行剖析，定位到 chunk-vender.js 存在耗时较高的状况，为性能瓶颈。

2、通过 webpack analyzer 对编译状况进行剖析：

发现存在以下问题：

• 业务域代码中 chunk-vendors.js 打包了微前端框架底座 biz-crm-fe-common 模块，这部分能力能够在主利用中提供，业务模块打包是应该排掉。
• 局部依赖库（bce-sdk、tangram-ui、moment、lodash）体积微小，须要思考作为公共依赖放入主利用，或者在页面通过 Promise 异步加载。
• 代码库路由较多，复用组件较多，导致 chunk-common.js 体积较大，且动态资源整体体积大。

计划：

链路：

1. 动态资源间接申请 BOS 域名，不走 aifanfan.baidu 域名，缩小一层 BFE 转发链路
2. 开启百度云 BOS CDN 减速
3. 开启动态资源 gzip 压缩

缓存：

1. 在首页中预加载线索列表相干动态资源
2. 在 HTML 预加载线索列表相干 JS，利用 webpack require 个性，全局缓存列表相干 JS（该计划是计划 1 的进阶版，预加载更前置、彻底）

编译：

1. 批改微前端框架 tangram-sdk 编译配置，排除 biz-crm-fe-commom 包
2. 拆分前端代码库。将列表和详情之外的非核心页面迁徙新代码库，保障列表 js 体积最小化
3. 进行异步加载大体积依赖 js，使得初始化加载 js 体积压缩到极致

收益：

1. 动态资源耗时（P90）从 2000+ms，优化至 500ms 以下
2. 动态资源gizp 总体积：693.52KB → 228.83KB，总体积放大 67%

附编译优化前后 js 体积比照（飘绿为优化后）

6.3.4 体验优化

问题：

1. 列表全屏 loading，白屏工夫长；
2. 列表筛选条件全副、实时加载，客户感知工夫长，且会有抖动；
3. 表头数据默认值可全选（50+ 列），申请、渲染数据量大。用户在应用时须要横向滑动 3 - 5 屏，体验不佳。

计划：

1. 列表筛选应用侧拉面板交互，本地记忆上次筛选条件并展现；
2. 优化 loading 区域及形式，从视觉感知上最小化用户感知时长；
3. 通过对所有用户自定义表头设置数据分析，及参考业界通用设置，减少表头数量下限。

收益：

性能优化和体验晋升必由之路。在 UBS 调研中，爱番番线索管家整体体验和性能在业界均处于领先地位。

6.4 收益

通过上述优化伎俩，线索列表整体性能达标。

回顾将近一年的性能优化旅程，大抵经验了上面几个阶段：

1. 「无从下手」用户反馈列表性能存在问题，尝试解决，但无奈度量，在黑暗中摸索。（20 年 Q4 — 21 年 Q1）
2. 「磨刀不误砍柴工」调研前端性能监控解决方案，启动爱番番大前端 APM Topic。（21 年 Q1）
3. 「对症下药」APM 建设，web 端全面落地。对线索列表性能有全面理解，优化工作逐渐清晰清朗。（21 年 Q2）
4. 「先摘高扬果实」应用惯例伎俩，对前后端常见性能问题进行解决和优化。（21 年 Q3）
5. 「难点攻坚、毫秒必争」不放过任何一个优化点，对前后端难点问题别离成立专项小组，集思广益，重点攻坚，不拿后果誓不罢休。（21 年 Q4）

三、总结

「以客户为核心，技术为产品服务」是爱番番线索管家团队始终遵循的准则。技术架构的布局首先应该围绕业务诉求开展，用正当的技术赋能产品，产品在一直的演进中对技术提出更高的规范和要求。线索列表是爱番番泛滥外围性能其中的一点，但管中窥豹，技术问题往往要从业务中寻找答案，了解业务是发展技术的前提。同时，业务的复杂度降级反哺技术架构进化。业务与技术相互促进，相辅相成，最终为用户发明价值。

产品和技术演进只有终点，没有起点。展望未来，线索列表能力通用化，配置扩大能力向 PaaS 平台演进，LowCode 及 NoCode 等方向均须要持续摸索实际，咱们要走的路还很长。

===

四、作者介绍

本篇系爱番番线索管家团队多位同学独特编写。

• 飞邪：架构师，善于通过微服务架构和 DDD 落地简单零碎
• TJ：设计师出身，致力向服务端转型的前端开发
• Hana：一只耕耘在 To B 行业的设计狮
• 东拾：资深研发工程师，善于业务零碎架构设计
• 三木:  web 前端工程师，善于各种撸猫

五、举荐浏览：

百度 APP 视频播放中的解码优化

百度爱番番实时 CDP 建设实际

当技术重构遇上 DDD，如何实现业务、技术双赢？

接口文档主动更改？百度程序员开发效率 MAX 的秘诀

技术揭秘！百度搜寻中台低代码的摸索与实际

百度智能云实战——动态文件 CDN 减速

化繁为简 – 百度智能小程序主数据架构实战总结

———- END ———-

百度 Geek 说

百度官网技术公众号上线啦！

技术干货 · 行业资讯 · 线上沙龙 · 行业大会

招聘信息 · 内推信息 · 技术书籍 · 百度周边