如何在react应用中一次渲染100万条数据？
查看详情
直接渲染100万的数据肯定是不行的，有几种方法：
- 虚拟列表：只渲染可视范围内的数据
- Canvas / WebGL 渲染：如果只是“展示数据点”而非交互 DOM，可用 Canvas/WebGL 绘制，性能数量级更高。
如何实现一个大文件上传功能？
查看详情
- 文件分片：使用浏览器原生的 Blob.prototype.slice 将文件切成固定大小的小块（如 2MB）
- 生成文件唯一标识：可以用 spark-md5 之类的库快速生成 hash
- 分片上传 + 并发控制：利用 Promise.all 并结合并发池（比如限制同时最多 5 个请求），每个分片用 FormData 上传
- 通知后端合并：当所有分片上传完成，最后请求一个 /merge 接口让后端进行合并
秒传 & 断点续传：
- 上传前先请求后端：/verify?hash=xxx
- 返回是否存在整文件。
- 返回已上传分片列表。
- 前端跳过已上传分片，只上传缺失的。
如何做H5移动端适配？
查看详情
- 视口（viewport）设置——移动适配的基础：
<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no"> - 布局方案
- rem + flexible 布局
- vw / vh 适配
- 媒体查询（辅助方案）
- 1px 边框问题
- 用 transform scale(1/DPR) 缩放 + 媒体查询
- 借助PostCSS的postcss-write-svg我们能直接使用border-image和background-image创建svg的1px边框
- 图片适配
- 使用media查询判断不同的设备像素比来显示不同精度的图片，只能用于背景图
- 使用image-set，只能用于背景图
- 使用img标签的srcset属性，浏览器会自动根据像素密度匹配最佳显示图片
- JavaScript拼接图片url
- 使用SVG图
如何修改第三方的npm包？
查看详情
- 直接修改node_modules中的代码
- 适合快速验证或一次性调试
- 缺点是重新install会被覆盖，CI/CD流程不会同步修改
- 使用 patch-package
- 无需 fork，维护简单；CI/CD 自动应用补丁；团队共享，无额外构建复杂度
- 不适合重写大量代码（patch 太大不好维护）
- Fork 源码 + 自行发包
- 改动自由，可长期维护
- 要维护自己的 fork，升级官方包时可能要手动 merge 改动，产生代码冲突可能性很大
- 重写部分模块然后通过 webpack alias / resolve.alias 来“劫持”模块导入路径
- 不改 node_modules，也不用 patch，适合替换单个文件或模块
- 不适用于替换大量的逻辑
在react项目中常见的设计模式有哪些？
查看详情
- Container-Presenter 模式
- 核心思想：UI 跟数据逻辑分开。
- 优点：干净、可测试、UI 可复用。
- Presenter（纯 UI）：只负责展示 props，不管数据来源。
- Container（数据容器）：负责请求 GraphQL、处理状态、然后把数据传给 UI。
ts
// Container
const UserContainer = () => {
const { data } = useUserQuery();
return <UserView user={data.user} />;
};
// Presenter
const UserView = ({ user }: { user: User }) => (
<div>{user.name}</div>
);- Custom Hooks 封装数据逻辑
- 把查询、状态、缓存策略封装进 hooks
- GraphQL + TS 类型安全管道
- GraphQL schema → codegen → TS 类型 → UI
- Facade + Repository 层封装 API 调用
- 不要在组件里直接写 useQuery/useMutation。
- 封装成一个「服务层」，后面想切换 GraphQL Client、加缓存策略、合并请求，对 UI 零侵入。
ts
// /src/services/userRepository.ts
export const userRepository = {
getUser() {
return useUserQuery();
},
update(name: string) {
return useUpdateUserMutation();
},
};- Fragments 复用视图数据结构
graphql
fragment UserBase on User {
id
name
avatar
}在react项目中如何设计状态管理？是否使用 Redux/Zustand，如何划分模块与数据流？
查看详情
- 选型
- Redux（含 Redux Toolkit）
- 适用场景：中大型系统，数据流复杂，跨模块状态共享频繁。
- 优点：可预测性强（单向数据流）、可调试性高（Redux DevTools）、社区成熟、支持中间件（如异步逻辑、日志）。
- 缺点：样板代码多，但使用 Redux Toolkit + createSlice 可以大幅简化。
- Zustand / Jotai / Recoil
- 适用场景：小到中型项目，局部状态或 UI 状态管理。
- 优点：API 极简，学习成本低，性能开销小。
- 缺点：缺少成熟生态，复杂业务逻辑和中间件支持有限。
- useReducer
- 模块划分
- 按业务领域划分 slice / store，每个 slice 只关心自己的业务逻辑，解耦性强
- UI 状态单独管理，modal、loading、tab 切换、分页等临时 UI 状态可以用单独 slice 管理。
- API / 异步数据，统一用 RTK Query 或自建 thunk 来处理异步请求，保证 loading/error 状态可追踪。
- 数据流设计
- 单向数据流：
- 组件 dispatch action → slice 更新 state → selector 供组件读取
- 异步逻辑通过 middleware 或 thunk 处理，结果回到 store
- 尽量局部化
- 高频变化或组件私有状态不放到全局 store，避免不必要的重渲染。
- 衍生状态 / 计算状态
- 使用 selectors 或 useMemo 处理，避免在 store 中存冗余数据。
引入 ESLint + Prettier + Husky + Jest 的落地过程？遇到哪些阻力，如何推动？
查看详情
- 落地流程
- 分析现状：所有规则使用warning，代码风格样式不统一
- 配置ESLint + Prettier：选择Standard规则集
- 配置Husky：对于改动到的文件不能有warning
- jest：新代码和重构代码时写单元测试
- CI/CD：添加GitHub actions任务，在代码提交时运行eslint检查和单元测试
- 阻力
- 历史遗留代码量大，改动就要修复所有问题
- 单元测试太费时间
- 如何推动
- 新功能严格执行 ESLint + Prettier + Husky + jest
- 历史代码逐步修复或者优先修复高优先级的问题
- 使用AI编写单元测试
- CI/CD 强制执行，不通过 lint/test，就不能合并。
CI/CD 流程具体包含哪些步骤？
查看详情
- PR阶段
- eslint, tsc检查
- 单元测试
- merge到主分支
- eslint, tsc检查
- 单元测试
- build
- build产物上传S3
- 部署
- 传统服务器/Nginx：替换 /usr/share/nginx/html，并执行健康检查
- 前端CDN：将构建包推送 CDN Origin，并 Cache Invalidate
你是如何设计 单元测试 测试策略的？
查看详情
核心准则是：把测试资源花在“出错代价高的地方”。
策略是：
- 公共函数，hooks -> 必测
- 公共组件 -> 选测（不测内部实现，测组件行为））
- 业务逻辑 -> 必测
- UI -> 不测
单元测试、集成测试、E2E 的覆盖重点是什么？
查看详情
- 单元测试：目标是保证逻辑的可靠，主要覆盖纯函数、业务计算、数据转换等
- 集成测试：确保模块之间正确协作，主要覆盖组件与API、store、service的交互
- E2E：保障用户关键路径可用，主要覆盖重要的业务流程
如何通过 Sprint 优化将上线准时率从约 70% 提升至 95%？具体措施有哪些？
查看详情
造成上线准时率低的原因：
- 需求细节不明确，开发过程中大量反复
- 设计稿频繁改动
- 优先级不真实
- 不开站会，不同步开发进度
- 做完的需求不主动自测、提测、验收
我的措施：
- 引入更严格的「Ready Definition」，需求必须满足：
- 流程清晰
- 验收标准明确
- 设计稿定稿
- 外部依赖准备好
- 需求优先级真实
- 每个开发领取的任务尽可能包含不同优先级
- 每天先开站会，同步进度、阻碍
- Sprint 中期检查
- 需求完成后必须主动自测、提测、验收（和jira中状态对应）
- 回顾会议
前端缺陷率下降 40%，如何量化与归因？做了哪些改进？
查看详情
- 量化：导出每个季度jira ticket进行统计
- 归因：通过回顾会议，确定“可追踪到行为改变”的改进
- 改进：
- 需求准入门槛变严，减少返工
- 优化CI流程：eslint、prettier、tsc、UT
- code review
- 自测、提测、验收
TypeScript 全量迁移的步骤与风险点？如何保证迁移不影响功能？
查看详情
- 迁移步骤
- ts依赖安装与配置
- 建立flow类型与ts类型的映射
- 使用脚本修改后缀名
- 删除/替换flow特有代码
- 增量启用严格模式
- 风险点与应对策略
- 大规模重构引入bug：依赖自测与E2E、测试手动测试
- 类型定义不准确/类缺失：逐步完善
Storybook 文档体系如何建立？如何保证组件文档与代码同步？
查看详情
如何建立文档体系：
- 规范公共组件的目录，将组件和组件的stories文件以及相关类型、测试文件等放在一起。
- 使用storybook CSF格式而不是MDX。这样有TS类型联动，args+controls可自动展示属性变化
- 安装storybook插件，建立交互文档，展示组件状态变化，让设计稿和代码对齐
如何保证组件文档和代码同步：
- PR模板写上检查组件更新的项目
- 使用react-docgen-typescript 自动从 TS 类型生成 API 表格
Renovate/Dependabot 的依赖管理策略？如何控制升级风险？
查看详情
依赖升级的目标：
- 保持依赖安全性（修补漏洞、满足 Audit）
- 降低技术债（避免多年不动导致大版本断层）
- 把升级成本分散到每周，而不是积累成一次无法承受的大手术
策略：
- 依赖分级
- 补丁版本
- 次要版本
- 主要版本
- 频率分级
- 自动在每周末创建一定数量补丁版本和次要版本的升级PR
- 手动触发主要版本的升级PR创建
如何控制升级的风险
- CI
- eslint
- tsc
- build
- UT
- E2E
- code review
- 手动验证
业务指标 Dashboard 的设计思路？如何选择指标与可视化方式？
查看详情
设计思路：
- 先问清业务的目标是什么
- 找到驱动结果的关键行为动作
- 把动作变成可量化指标
- 根据指标选择对应的图表
- 饼图
- 折线图/柱状图
- 漏斗图
如何通过数据驱动决策？举一个具体的数据发现与改进案例。
查看详情
通过分析每个码头最终集装箱被预约的时间来优化自动预约脚本。
项目中遇到的最具挑战性的技术问题是什么？如何分析与解决的？
查看详情
在无人指导的情况下整理flutter项目的开发、部署文档。
如何平衡开发速度与代码质量？
查看详情
- 开发速度不应该直接影响代码质量
- 接受临时方案和无UT的代码，但也应该保证功能可用无bug
- 规范不可妥协
作为 Scrum Master，如何应对 Sprint 中的突发需求或变更？
查看详情
- 快速评估需求
- 优先级/紧急程度
- 价值
- 对当前sprint已排任务的影响
- 开发
- 测试
- 部署
- 决定处理策略
- 延期到下个sprint
- 纳入当前sprint
- 优先处理突发需求中高价值的点
- 调整当前sprint的需求
- 及时同步进度
如何保持技术敏感度？最近关注的技术点有哪些？
查看详情
如何保持技术敏感度：
- 阅读官方文档
- 追踪release note
- 关注前端领域内的会议，例如：react conf
- 关注前端领域内的调研：例如：state of js
- 技术博客/社区文章
- GitHub
- 动手制作demo验证
最近关注的技术点：
RN 工程架构重构的动因与方案？如何提升可维护性与扩展性？ 跨端协作中如何统一编码规范与组件封装？如何保证 iOS/Android 一致性？ RN 组件系统如何设计？如何提升复用性与可扩展性？ RN APP 的性能优化重点？如何定位与解决卡顿问题？ 如何处理 RN 中的状态管理与导航？Redux Toolkit 与 React Navigation 的配合？