字节内转线索一面
即创试水这次总算不是温水煮青蛙了，效果好一点点，但不知道过不过欸。毕竟，回答过程还是带着点吞吐或者不知道回答什么都现象。
OS：为什么把我之前的简历也翻出来了，这 part 是真的纯粹靠印象啊。
自我介绍。
谈到的特征淘汰展开讲一下。
如果一半可以淘汰另一半不可以，会怎么做？从数据里刨除这一条吗？还是选择重新发起一次任务呢？
聊到方案迁移，问其实是本身有一些元数据的基础信息，由他们一方做底表接入然后血缘查询对吗？
所以现在可能还是在试点落地阶段对吗？
你在这一整个需求流程中，你在其中做了些什么？
你们这个项目的技术栈？
微前端是你自己负责了主应用搭建和子应用接入吗？
子应用是如何复用主应用的鉴权机制的？
📌 回答
- 访问某个 URL 会触发公司内部的 SSO 拦截，如果没有登录信息会强制跳转并做登录认证。登录后主应用会派发 Garfish 事件进而更新 Garfish 里的一些配置，可能就是 props 里的 store 信息。
- 在 OceanCloud 退出登录会触发公共包里的 logout 函数，logout 会调用 @byted-sdk/bdsso 初始化后的 config 对象的 logout 函数。包 @ad/utils 里除了 login 和 logout 函数，还封装了通用的 useCloudJwt / useUserInfo 等通用的钩子函数。
- Garfish 可以通过 Garfish.run({ props: store }) 将 store 信息由主应用传递给子应用，子应用调用钩子，钩子转发 Garfish 里的全局信息。比如 useUserInfo 会直接转发 Garfish 里存储的用户信息，这也解释了为什么限制这些钩子的使用环境只能是在 Garfish 微前端环境里使用。
- 借助公共包能力，可以实现子应用使用全局登录状态，无需主应用的下发。但是 localStorage 会存储一些子应用的 Jwt。
微前端的优缺点和缺点对应的改进方案，主要是说了如何减少项目的启动数量。
📌 回答
优点：
- 解耦：每个子应用都是一个独立的项目，开发、测试、部署都是独立的。
- 技术栈无关：子应用可以使用任意的技术栈，主应用只需要支持 Garfish 即可。
- 隔离性：样式、路由、运行时状态相对隔离，不会相互影响。
- 渐进式改造：可以逐步替换旧系统，而不是一次性重构。
缺点：
- 性能开销：每个子应用都是一个独立的项目，会增加项目的启动数量，也会增加项目的启动时间。
- 运维复杂：项目数量多，启动、调式和部署成本高。
- 通信复杂：子应用之间的通信需要通过主应用进行转发，会增加通信的复杂度。
- 样式或依赖冲突：子应用的样式或依赖可能会与主应用冲突，导致样式错乱或功能异常。
- 一致性问题：UI 等一致性问题，需要主应用和子应用协调解决。
优化方案：
- 资源可以通过预加载或者懒加载的手段，依赖也可以通过共享的方式来减少重复加载。
- 低频的子应用可以通过 Iframe 或者远程加载，避免加载整个应用。
- BFF 实现聚合、模块联邦动态加载、相似业务通过路由区分合并到一个应用、本地开发代理，用于减少启动的项目数量。
- MonoRepo 和完整流水线，提高依赖复用，并且做到子应用的快速发布。
- 全局事件总线或者共享状态管理，用于子应用之间的通信。
- 统一组件库、制定开发约束等，防止应用之间的风格割裂。
类组件和函数组件的优缺点。
有自己封装的钩子吗？有没有碰到过性能问题？什么情况下考虑缓存策略？
低代码虚拟 Node 的结构。
对于选项组件 option 的值是随机的吗？options 不能排序？
你的物料或者问卷的数据表结构以及版本控制。不同版本是要覆盖还是新增？
手写元素碰撞检测。
手写三栏布局。
手写 MyReturnType。
如图：
