桌面端窗口尺寸无法记忆，且默认 1280×820 在高 DPI 屏幕上偏小

[PerseusNana7mi]

问题

DSH 桌面端（Windows / macOS）没有记忆主窗口尺寸和位置的能力。
每次关闭并重新启动后，窗口都会回到固定的默认大小。

环境：Windows，DSH 桌面端 v0.2.0-rc.2

复现步骤

1. 启动桌面端，把窗口拖拽放大到适合当前屏幕的尺寸（或最大化）
2. 完全退出应用（确认托盘也已退出）
3. 重新启动
4. 窗口回到 1280×820 默认尺寸，之前的大小和位置全部丢失

期望行为

记住上次的窗口尺寸与位置（含最大化状态），启动时恢复；
并在显示器配置变化或屏幕分辨率不足时回退到安全默认值。

影响

在 4K / 高 DPI 屏幕上，1280×820 的默认窗口只占屏幕很小一块，
首次打开时刻意显得局促，用户每次启动都要重新调整一次。

已确认的实现现状

我反编译了本地安装包的 app.asar，v0.2.0-rc.2 的主进程
（apps/desktop/src/main.ts → lib/main.js）中主窗口尺寸是硬编码的：

const window = new BrowserWindow({
    width: 1280,
    height: 820,
    minWidth: 520,
    minHeight: 600,
    ...
});

全仓库范围内没有任何窗口 bounds 的持久化逻辑：

• main.ts 中没有 getNormalBounds / restoreBounds / will-resize 相关监听
• apps/desktop/src/settings.ts 中的 DesktopSettings 只包含
  updates.allowTestAuthPopupWindow，没有窗口几何字段
• 仓库 code search：window-state / electron-window-state /
  restoreBounds / getNormalBounds 命中均为 0

补充：提交 761f532（feat(desktop): align main window default and minimum
size with Codex, 1280x820 / min 480x600）只调整了默认值与最小宽度，
并未引入持久化，因此不解决本问题。

相关但不同的已有能力

v0.2.1-alpha.3 的「桌面端可用 Cmd/Ctrl + 加号或减号统一调整正文、代码和
终端字号」确实缓解了高 DPI 下的可读性问题（字号可持久化），
但它调整的是内容字号，窗口本身的尺寸仍不会被记住。

建议

为窗口几何增加持久化（如写入 userData 下的桌面设置文件），
保存正常状态下的 bounds 与最大化状态，并在启动时校验目标
显示器是否仍然存在、尺寸是否可用，不可用时回退到默认值。

个人体验上，把默认值提高到接近屏幕工作区的某个比例、或首次启动时
按屏幕分辨率自适应，也能明显改善高 DPI 屏幕上的第一印象。

[PerryLink]

这条是真的，我在代码里确认了：桌面端根本没有窗口尺寸的持久化，那个 1280×820 是写死的。

代码现状

apps/desktop/src/main.ts:208-213：

function createWindow(preload: string, show = false, primary = false): BrowserWindow {
  const window = new BrowserWindow({
    width: 1280,
    height: 820,
    minWidth: 520,
    minHeight: 600,

每次启动都按这四个常量建窗口，没有任何"上次的位置和大小"参与。

我又查了一遍有没有恢复逻辑，用的是 windowBounds / savedBounds / restoreBounds / bounds.json 四组关键词扫整个 apps/desktop/src——全 0 命中。也就是说不是"记住了但没生效"，是压根没实现。所以你观察到的"关掉再开又回到原样"是必然的。

顺带一个副产品：这个 createWindow 是所有窗口共用的（primary 参数只影响 Windows 上的标题栏样式），所以欢迎页、更新弹窗这些也都是同一组尺寸起点。要加持久化的话，得想清楚是只记主窗口还是全部。

关于"高 DPI 上偏小"

这里有一点要提醒：Electron 的 width/height 用的是 DIP（设备无关像素），不是物理像素。所以在 150% 缩放的屏幕上，1280×820 DIP 实际占的是 1920×1230 物理像素，并不算小。

如果你的屏幕是 4K 但系统缩放设成了 100%，那确实会显得小——但那是缩放设置的效果，不是这个默认值算错了。建议你在报告里带上系统缩放比例，否则维护者可能会按"这是 DIP"回复你。

建议的诉求写法

把两件事分开，因为它们优先级不同：

1. 窗口尺寸/位置不持久化（这个是明确的缺口）——建议把 getBounds() 的结果存进一个 profile 级的文件，启动时校验后恢复（要处理显示器拔掉、分辨率变化导致坐标落到屏幕外的情况，这种情况应该回退到默认值而不是照搬）。
2. 默认尺寸在高 DPI 下观感偏小（这个是主观项）——如果仍要提，附上你的分辨率与缩放比例，让维护者判断要不要按屏幕尺寸动态给默认值。

第一条更容易被采纳，第二条容易被当成偏好之争。

一个可选的替代做法

minWidth: 520 / minHeight: 600 已经存在了，所以窗口本身能缩得很小。如果你只是嫌每次都要手动调大，短期内可以试试用 Electron 的窗口状态记忆能力——不过 DSH 没有引入这类依赖，自己写一个十来行的 getBounds 存读就够了，不需要加库。

边界

我核的是 origin/master = 571902028a（2026-10-14）上的 apps/desktop/src。

一点没法从这边确认的：你那份桌面端的版本号。桌面端此前一直停在 0.2.0-rc.2，而 npm 那条线已经到 0.2.1-alpha.3，两者不是同一份产物，所以如果你的桌面版实际是更早的构建，上面这个文件也可能和你看的不完全一样。方便的话把版本带上。

[tinroof71]

Windows 11 + 0.2.1-rc.2 独立复现：不是"没记住"，是这条路径不存在

补充一份来自 Windows 侧的独立验证，结论和 @PerryLink 的代码分析一致。

环境：Windows 11，DSH Desktop 0.2.1-rc.2（build 332895e0f7c9d4dbfb29729f5eb367fa263ff986，nightly 通道）

在本机安装包（app.asar）上的验证

• 主窗口仍是 width: 1280, height: 820, minWidth: 520, minHeight: 600 写死；createMainWindow() 调用 createWindow() 时不传任何尺寸参数。
• 整个 shell 搜不到 window-state / getNormalBounds / isMaximized / getDisplayMatching / restoreBounds。
• DESKTOP_IPC 通道表里没有任何窗口几何项（只有 windowFullscreen、nativeThemeSet、shortcuts* 等）。也就是说渲染进程连"请求保存/恢复尺寸"的能力都没有——这条链路两端都缺。
• %APPDATA%\@deepseek-ai\dsh-desktop\desktop\settings.json（本机唯一的状态文件）schema 只有 updates.allowTestAuthPopupWindow 一个字段，窗口几何无处可存；也没有生成任何 window-state.json 之类的文件。

结论：每次启动都按同一组常量建窗，是必然行为，不存在"上次的值"参与运算。

建议的实现（贴合现有结构，改动面很小）

1. 存储：复用现有的 readDesktopSettings / userData/desktop/settings.json，新增 window: { bounds, maximized }，不引入新的文件和新依赖。
2. 保存：close 时写入；最大化/全屏状态下要用 getNormalBounds()，不要把放大后的 bounds 覆盖掉正常尺寸，另存一个 maximized 布尔值。若要更平滑可在 will-resize / will-move 加防抖。
3. 恢复：启动时先用 screen.getDisplayMatching(saved).workArea 收敛；若目标显示器已不存在、或与可用工作区交集过小，则回退到居中默认值（避免"窗口在屏幕外"）。minWidth/minHeight 照旧生效。
4. 作用范围：只作用于主窗口（primary === true），欢迎页 / 更新弹窗 / 各种 overlay 保持现状——它们现在共用这个 createWindow，改的时候需要一个显式的开关而不是全量生效。
5. 隐私：只写本地 userData，不上传（与 桌面端启动时恢复上次的主窗口大小与位置 #9324 的验收条件一致）。

一个补充观察

#9324 已经提了同样的诉求（并且给了比较完整的验收条件），可以合起来看。

另外：nightly 源（download.deepseek.com/dsh-desk/feeds/win-x64/nightly.yml）里最新版本就是 0.2.1-rc.2（2026-10-17 发布），apps/desktop 在此之后没有新提交——也就是说即使想更新验证也没得验。如果后续版本加上了持久化，希望能在这里回一句，我可以在 Windows 上做回归（拖拽调整 → 退出 → 重启 → 对比 bounds，以及拔掉外接显示器后的回退行为）。