你运行的 Kimi Code 版本是？
0.40.1
你使用的是哪个开放平台/订阅？
Kimi 官方订阅（通过 /login 登录的 Kimi 账号）
你使用的是哪个模型？
k3（与模型无关，UI 层问题）
你的电脑平台是？
Darwin 25.6.0 arm64（macOS 26.6.2，Apple Silicon），Safari 26.6.2 (21624.5.1.11.3)
你遇到了什么问题？
macOS 上使用 Safari 打开 Kimi Code web 界面时，凡是触发布局变化的操作都会出现明显卡顿，最典型的场景：在底部输入框持续输入文字，每次触发自动换行（输入框高度变化、聊天区位置随之调整）时页面会卡住一拍。同样的操作在 Chrome 中完全流畅。
对发布的 dist-web bundle（0.40.1）做了静态分析，有两个高度可疑的性能问题：
-
常驻 backdrop-filter 放大重绘成本。主布局顶栏 .topbar 使用 backdrop-filter: saturate(150%) blur(12px) 覆盖在滚动聊天区之上，菜单为 blur(24px) saturate(1.8)。backdrop-filter 的开销与底层内容变化量成正比：主输入框（ProseMirror contenteditable，高度随内容自然增长）每次换行都会引起滚动区整体 reflow，顶栏模糊层随之重算——这是 WebKit 已知的昂贵路径，Blink 对此的复合优化明显更好。建议对 WebKit 降级为半透明纯色背景。
-
多处纯 textarea 的自动增高存在同步布局抖动（注：不涉及主输入框）。侧边聊天面板（SideChatPanel）和审批卡（ApprovalCard）反馈输入框的 resize 逻辑是 style.height="auto" → 读 scrollHeight → 再写 style.height 的 write→read→write 模式，SideChatPanel 将其绑定在 onInput 上，每次按键强制两次全文档同步 reflow。建议改为 rAF 合帧，或先测量后一次性写入。
bundle 中应用层有 Safari UA 嗅探，但仅用于文本断行行为（ProseMirror 库内部另有 Safari composition 的正确性变通），未见性能路径的差异化处理。
复现步骤？
- macOS 上用 Safari 打开 Kimi Code web 界面（本地 web 或远程访问链接均可），进入一个有一定长度对话的 session
- 在底部输入框持续输入，直到触发自动换行
- 每次换行页面明显卡顿；用 Chrome 打开同一地址做对照，无此现象
期望的行为是什么？
Safari 下输入和布局变化应与 Chrome 一样流畅。考虑到远程控制功能的主要目标设备是 iPhone/iPad——iOS/iPadOS 上所有浏览器均为 WebKit 内核，没有替代引擎可选——WebKit 性能实际上是该功能的唯一路径，而非小众兼容性问题。
补充信息
web 源码在 code-app 仓库，以上为对 kimi-code 仓库随附的预构建 bundle（apps/kimi-code/dist-web，0.40.1）的分析，文件名为构建哈希故未附行号，相关模式可直接在 bundle 中检索。如需要我可以提供 Safari Web Inspector 的 Timeline 录制。
你运行的 Kimi Code 版本是？
0.40.1
你使用的是哪个开放平台/订阅？
Kimi 官方订阅（通过
/login登录的 Kimi 账号）你使用的是哪个模型？
k3（与模型无关，UI 层问题）
你的电脑平台是？
Darwin 25.6.0 arm64（macOS 26.6.2，Apple Silicon），Safari 26.6.2 (21624.5.1.11.3)
你遇到了什么问题？
macOS 上使用 Safari 打开 Kimi Code web 界面时，凡是触发布局变化的操作都会出现明显卡顿，最典型的场景：在底部输入框持续输入文字，每次触发自动换行（输入框高度变化、聊天区位置随之调整）时页面会卡住一拍。同样的操作在 Chrome 中完全流畅。
对发布的
dist-webbundle（0.40.1）做了静态分析，有两个高度可疑的性能问题：常驻 backdrop-filter 放大重绘成本。主布局顶栏
.topbar使用backdrop-filter: saturate(150%) blur(12px)覆盖在滚动聊天区之上，菜单为blur(24px) saturate(1.8)。backdrop-filter 的开销与底层内容变化量成正比：主输入框（ProseMirror contenteditable，高度随内容自然增长）每次换行都会引起滚动区整体 reflow，顶栏模糊层随之重算——这是 WebKit 已知的昂贵路径，Blink 对此的复合优化明显更好。建议对 WebKit 降级为半透明纯色背景。多处纯 textarea 的自动增高存在同步布局抖动（注：不涉及主输入框）。侧边聊天面板（SideChatPanel）和审批卡（ApprovalCard）反馈输入框的 resize 逻辑是
style.height="auto"→ 读scrollHeight→ 再写style.height的 write→read→write 模式，SideChatPanel 将其绑定在onInput上，每次按键强制两次全文档同步 reflow。建议改为 rAF 合帧，或先测量后一次性写入。bundle 中应用层有 Safari UA 嗅探，但仅用于文本断行行为（ProseMirror 库内部另有 Safari composition 的正确性变通），未见性能路径的差异化处理。
复现步骤？
期望的行为是什么？
Safari 下输入和布局变化应与 Chrome 一样流畅。考虑到远程控制功能的主要目标设备是 iPhone/iPad——iOS/iPadOS 上所有浏览器均为 WebKit 内核，没有替代引擎可选——WebKit 性能实际上是该功能的唯一路径，而非小众兼容性问题。
补充信息
web 源码在 code-app 仓库，以上为对 kimi-code 仓库随附的预构建 bundle（
apps/kimi-code/dist-web，0.40.1）的分析，文件名为构建哈希故未附行号，相关模式可直接在 bundle 中检索。如需要我可以提供 Safari Web Inspector 的 Timeline 录制。