Canvas相关
- 在针对图片预览、图谱拖拽、草稿板绘图等高交互组件进行专项优化时，你首先从哪些维度去评估这些组件的性能瓶颈？请结合具体场景说明，比如如何判断图片预览组件存在性能问题，以及使用了哪些工具或方法进行检测？
- 项目中解决了 Markdown 图片与第三方组件的冲突问题，请问当时 Markdown 图片与第三方组件具体表现出了哪些冲突现象？你是如何定位到冲突根源的（比如是 DOM 结构冲突、样式冲突还是事件冲突等）？最终采用了哪些技术方案解决该冲突，为什么选择这些方案，有没有考虑过其他方案，它们的优缺点是什么？
- 重构 d3 图谱展开逻辑时，遇到了初次渲染状态不一致的问题。请详细描述初次渲染状态不一致具体体现在哪些方面？在排查这个问题的过程中，你从 d3 的渲染机制、数据绑定逻辑、DOM 生成顺序等哪些角度进行了分析？最终通过怎样的代码调整或逻辑优化解决了该问题，调整后的代码逻辑是怎样的？
- 针对 d3 图谱点击事件失效的问题，可能存在多种原因，比如事件委托问题、元素层级遮挡、事件绑定时机错误等。在你的项目中，d3 图谱点击事件失效是由哪种或哪些原因导致的？你是通过哪些调试手段（如浏览器开发者工具的哪些面板、断点调试的关键位置等）定位到具体原因的？解决该问题的具体步骤和代码实现是怎样的？
- 优化 Canvas 草稿板灵敏度与响应速度时，灵敏度低和响应速度慢分别表现为什么现象？比如在绘制线条时是否出现卡顿、线条与鼠标轨迹不同步等情况。你从 Canvas 的绘制机制（如重绘区域、绘制频率）、事件监听（如鼠标事件的触发时机、事件处理函数的复杂度）等方面采取了哪些优化措施？请举例说明优化前后的性能差异（可从帧率、响应延迟等指标描述）。
- 在对高交互组件进行专项优化的过程中，不可避免地会涉及到代码重构。请问你在重构 d3 图谱展开逻辑和 Canvas 草稿板相关代码时，遵循了哪些代码设计原则（如单一职责原则、开闭原则等）？如何保证重构后的代码兼容性和稳定性？比如是否进行了充分的单元测试、集成测试，测试用例是如何设计的？
- 对于图片预览组件的专项优化，除了常规的图片懒加载、图片压缩等方案，你还考虑过哪些针对高交互场景的优化方式？比如在图片预览时支持缩放、旋转等交互操作，如何优化这些操作的流畅性？是否遇到过因图片过大导致交互操作卡顿的问题，如何解决的？
- d3 图谱展开逻辑重构后，除了解决初次渲染状态不一致和点击事件失效的问题，在图谱的扩展性和可维护性方面有哪些提升？比如后续如果需要新增图谱节点的类型、修改节点的样式或交互逻辑，如何在现有代码基础上进行扩展？代码的模块化程度如何，各模块之间的耦合度是怎样的？
- Canvas 草稿板在优化响应速度时，是否考虑过使用 Web Worker 来处理一些复杂的计算任务（如线条的平滑处理、图形的碰撞检测等）？如果使用了，Web Worker 与主线程之间的数据通信是如何设计的，如何避免因数据通信频繁导致的性能问题？如果没有使用，说明原因以及采用了其他哪些替代方案。
- 在整个项目的组件优化过程中，你是如何平衡优化效果与开发成本的？比如某个优化方案虽然能显著提升性能，但需要大量的开发时间和人力投入，你会如何决策？请结合具体的优化场景（如图片预览、图谱拖拽或草稿板绘图）说明你的决策过程和依据。
