💬 👧：如果让你设计一个高性能日志系统，你会怎么做？
📌 👦：
我会从采集—传输—存储—分析四层来设计。
1️⃣ 日志采集：业务端用轻量 SDK 或 Agent（比如 Filebeat/自研），异步写入，保证业务不被阻塞。
2️⃣ 日志传输：放到高吞吐的消息队列（Kafka），支持分区和批量发送，顺序性和扩展性都有保障。
3️⃣ 日志存储：热数据放 Elasticsearch 或 ClickHouse，查询快；冷数据放对象存储归档，节约成本。分区、索引和压缩策略要做好。
4️⃣ 日志处理与分析：
- 实时分析用流处理（Flink/Spark Streaming），支持报警和监控。
- 离线分析用批处理（Spark/Hadoop），统计和报表更方便。
🔥 性能优化点：
- 异步写入 + 批量处理
- 数据压缩，索引优化
- 水平扩展，防单点瓶颈
- 限流和背压，避免暴涨日志压垮系统
💬 👧：如果让你设计一个微前端架构，你会怎么做？
📌 👦：
“微前端其实就是把大前端拆成小模块，各个团队可以独立开发、部署，同时整合在一起呈现。我的设计思路主要从 拆分—集成—通信—运维 四个方面考虑：
1️⃣ 拆分应用：按业务域拆分子应用，每个子应用独立开发、独立路由、独立部署，可以用 React/Vue/Svelte 都行。
2️⃣ 集成方式：
- 客户端集成：通过 JS 沙箱、iframe 或 Web Components，保证不同子应用互不干扰。
- 服务端集成：服务端拼接 HTML，也可以保证加载速度和 SEO。
3️⃣ 通信机制：
- 跨子应用事件总线（比如自研 EventBus 或 Redux/GlobalStore）
- URL 或 query 参数传递状态
4️⃣ 部署和运维：
- 子应用独立部署，版本升级互不影响
- 静态资源 CDN 加速，合理缓存策略
- CI/CD 自动化部署，保证线上快速迭代
🔥 优化点：
- 避免重复依赖，多子应用共享公共库
- 按需加载，减少首次渲染体积
- 沙箱隔离，防止样式或 JS 冲突
⚡ 总结一下：微前端就是把“大前端”拆成“小而独立”的模块，既能独立迭代，也能统一呈现，核心是解耦、独立部署和高性能加载。”
💬 👧：如果让你构建一个高扩展性的业务组件库，你会怎么做？
📌 👦：
“高扩展性组件库的核心目标是：可复用、易扩展、可维护。我的设计思路主要从 架构—组件设计—主题/样式—发布维护 四个方面考虑：
1️⃣ 架构设计：
- 按功能模块划分组件包（Form、Table、Modal 等）
- 支持按需加载，减小打包体积
- 提供统一的入口和类型定义（TypeScript）
2️⃣ 组件设计：
- 原子化：拆小、可组合
- 高可配置：通过 props、slots/children 传递行为和内容
- 可扩展：支持 HOC、Render Props 或 Hook 封装增强功能
- 状态管理解耦：组件尽量无副作用，业务状态由外部传入
3️⃣ 主题和样式：
- 样式变量化、支持主题切换
- 尽量使用 CSS-in-JS 或 CSS Modules 避免全局污染
- 支持暗黑模式、响应式布局
4️⃣ 发布与运维：
- 单独打包每个组件，支持 npm 或私服发布
- 版本管理遵循 SemVer，向前兼容
- 提供 Storybook / 文档站点，方便团队使用
🔥 优化点：
- 公共工具库抽离，避免重复依赖
- 性能优化：按需加载、懒渲染
- 测试覆盖：单元测试 + 视觉回归
⚡ 总结一下：高扩展性的组件库就是拆小可组合、高可配置、低耦合，让团队能快速复用，又能安全迭代。”
💬 👧：如何设计一个支持 10 万级节点的虚拟滚动树组件？
📌 👦：
“核心目标就是高性能渲染 + 可扩展 + 用户体验流畅。我会从 数据结构、渲染策略、交互优化、性能优化 四方面设计：
1️⃣ 数据结构设计：
- 树形数据按层级组织，节点加唯一 id 和父子关系索引
- 支持懒加载和动态展开，避免一次性渲染全部节点
2️⃣ 虚拟滚动渲染：
- 只渲染可视区域的节点，滚动时动态计算渲染窗口
- 支持高度不固定的节点，通过缓存节点高度加快计算
- 可复用 DOM 节点，减少创建销毁成本
3️⃣ 交互优化：
- 展开/收起、选择、拖拽操作仅更新必要节点
- 节点状态变化用局部更新（React memo/shouldComponentUpdate）
4️⃣ 性能优化：
- 批量更新 + requestAnimationFrame 节流
- 节点高度缓存 + 滚动位置预测
- 分片渲染大数据量，防止主线程卡顿
⚡ 总结一下：虚拟滚动树就是只渲染可见 + 按需加载 + 精准局部更新，核心是性能与用户体验并重。”
