1.你简历上提到你做的是财务系统，能不能讲讲你在项目里是怎么处理复杂业务逻辑和数据校验的？ - 及时校验：一般是通过react-hook-form、formily - 提交时校验：前端校验只是为了用户体验，不能决定什么。
2.财务系统里很多审批逻辑你们的审批流是怎么设计的？怎么去适配这种动态流程？ - 就都是后端决定，前端只是视图表现。重新请求然后更新组件即可。 - 前端根据不同的类型，动态渲染节点。比如像“驳回”、“通过”这种按钮，就是根据权限和流程动态渲染的。 - 还区分“会签”和“或签”节点。
3.那像你说审批流程是靠后端返回的，如果后端信息缺失或者异常了，你前端怎么做 - 其一，前端要做好数据兜底，应对任何一个字段缺失的情况。 - 其二，应该设计明确的提示，通知用户节点节点缺失或者网络异常等等。
4.页面权限动态控制是怎么实现的？ - 分两种，一种的菜单路由权限，是否能访问。我们一般是产品同学专门在一个平台上配置，然后用载入的时候根据权限动态返回路由表。 - 然后我们前端会过滤掉不在表上的路由。 - 至于操作按钮，就属于普通的业务逻辑了，取决于具体的要求，一般实现方式是，在组件的当前层定义一个变量，然后根据变量值来决定是否渲染。
5.怎么处理跨节点、跨角色的多级审批状态管理？如果中途某一节点要“退回上一级”，你怎么做状态恢复和视图还原？ - 这里分两种情况，一种就是我们目前讨论的审批流组件 - 前端依然是通过api发起请求，后端返回结果即可。
6.审批流程中如果存在动态插入流程节点（比如加签、转办）怎么处理 - 同上的，通过模态框或者抽屉组件显示，然后通过api发起请求，后端返回结果，再重渲染即可。 7.比如审批人在高铁上审批，接口请求失败后还能保留上次编辑状态吗，这种怎么处理？ - 状态一般会存在前端State中，不刷新页面就没事。 - localStorge、sessionStorge。 - Service Worker 与 Background Sync（会存进indexDB） 8.比如 A 用户审批失败，运营想看到他点了哪些按钮、看了哪些页面，你们的打点埋点是怎么串起来的？ - 8.比如 A 用户审批失败，运营想看到他点了哪些按钮、看了哪些页面，你们的打点埋点是怎么串起来的？ - 埋点方式：PV加在路由当中，点击事件加在按钮上。 - 串联信息： - 用户标识 - 会话标识：储存本次会话的标识，用于区分不同会话。 - 流程标识：记录一次完成的业务流程链路。 - 统一上报。
9.如果后端日志平台挂了，你们打点系统怎么兜底？ 10.日志打点是怎么实现的？代码是怎么接入的？ 11.实时告警怎么做的，比如高频错误能不能立马通知到你们
12.你知道你们日志打点的底层是怎么实现的吗？你能说一下整个流程？ 13.前端代码是怎么接入的，谁来定义打点行为、按钮、事件这些？
如果讲主体的难点
我觉得前端的技术难点主要是在具体的业务场景上，难点主要在前人埋的坑和业务逻辑上面，所以我的叙述尽量都会放在一个具体的项目以及业务背景下：
面对这个React15老项目，我的首要目的是管理项目分析，确保需求不延期，以及保证研发质量，bug要少一些。因为缺乏开发文档和原开发人员的交接，我需要一个系统化的策略来迅速上手项目；
首先我没有直接去看代码，而是从用户视角出发，去测试环境把整个任务流程全部操作了一边；然后记录没个操作所在的页面，触发的请求以及返回，都记录了下来，形成了一张业务行为到具体实现的表格。
然后，初步形成这个表格之后，我再去看代码，通过debugger的方式，一层一层的调试，去看核心数据是在哪里请求的，以及从哪里传进来的。在这个过程中，我遇到了很多困难和麻烦的地方： 比如它的类组件有不少不明类型的“this”传递，以及它的ts类型大量使用了any，所以我不得不用debugger一层一层调试，以明确它在嵌套的哪一层进行了何种数据处理。
这里最麻烦最复杂的一个点是，要梳理不同类型的审批流（比如分境外和境内）对于不同身份角色（比如申请人，审批人，执行人）的权限判断，比如，有些审批流中的表单存在复用的情况，那么就需要通过审批流的类型，来决定这些表单是否隐藏。这里就会加一层复杂度。 再比如，在某种审批流的过程中，有一些信息需要对某种身份的人进行隐藏，那么就需要通过角色身份信息来决定一个item是否显示，以上两种情况，都决定一个表单item是否显示，但是他们的逻辑都是耦合在一起的。
除此之外，表单还需要开放在某些审批节点，对于有权限的人，的编辑能力，这一层逻辑也耦合在了上面的层层封装里面。
我上面说了，因为这里的表单项存在复用，因此会出现。一个页面的全部表单，不一定在同一个大组件里面的情况，它可能额外套了几层，而这里的数据传递，完全没有使用任何状态管理，就是一层一层传下去的。
针对这些情况，我是画了每个页面的模块嵌套图，梳理清楚了它这个模块到底嵌套了几层，每一层又做了什么事情，以及这一层使用的组件，又在哪里复用了。以及这个组件，根据不同的使用场景，隐藏了或者显示了哪些item。
业务难点总结
这是业务一个item是否显示，以及它显示之后，是处于可操作的状态，还是禁用的状态。 这些需要根据审批类型，审批节点状态，以及人员权限来判断。
我这样算是把我的难点讲清楚了吗？
然后代码上的难点是，我在更改一个组件的时候，我需要去看它的所有调用情况，就跟走钢丝一样，要避免引入新的bug，同时还要考虑我所熟悉的语法在这个项目的兼容性。