• 桌面应用
• 开发工具
• 插件系统

导读

本文基于 PicGo 官方 Changelog（changelog/2.4.2.md）及当前仓库源码，深入剖析 2.4.2 版本的三项核心能力：macOS 应用签名与公证流程的落地实现、图床配置一键复制与删除二次确认的交互改进、以及通知系统重构后新增的notificationSound设置项。读完本文，你将掌握这些新特性背后的配置参数、底层实现原理与源码调用链，并了解两个 Bug 修复与一次存储层重构的细节。

一、版本概览：2.4.2 带来了什么

PicGo 2.4.2 是一个以「体验打磨」为核心的小版本更新，主要内容集中在三个方面：

• macOS 版本签名 + 公证（Notarization）：下载安装后不再需要手动放行，开箱即用；
• 图床配置复制按钮 + 二次确认弹窗：一键复制已有图床配置，且复制与删除均有确认步骤，防止误操作；
• 通知系统重构 +notificationSound设置：上传结果通知改为可通过配置关闭声音提示。

同时修复了两个视觉相关 Bug，并完成了一次存储层重构（移除 config store）。下文将逐一展开。

二、macOS 签名与公证：从「手动放行」到「开箱即用」

2.1 解决的问题

此前 PicGo 的 macOS 安装包未经过 Apple 公证，用户首次打开时需要在「系统设置 → 隐私与安全性」中手动放行，这对普通用户而言存在门槛。2.4.2 起，安装包完成签名 + 公证，用户可以直接下载安装使用。

2.2 源码层面的实现

公证逻辑由 scripts/notarize.js 承载，它通过@electron/notarize（仓库依赖版本 2.5.0，见 pnpm-lock.yaml）在应用打包完成后自动提交 Apple 进行公证：

const { notarize } = require('@electron/notarize') const { APPLE_ID, APPLE_TEAM_ID, APPLE_APP_SPECIFIC_PASSWORD } = process.env const APP_BUNDLE_ID = 'com.molunerfinn.picgo' async function main(context) { const { electronPlatformName, appOutDir, packager } = context // 仅在 macOS 平台且三项 Apple 凭证齐全时才执行公证，否则跳过 if ( electronPlatformName !== 'darwin' || !APPLE_ID || !APPLE_APP_SPECIFIC_PASSWORD || !APPLE_TEAM_ID ) { console.log('Skip notarization.') return } const appName = packager.appInfo.productFilename const appPath = `${appOutDir}/${appName}.app` const now = Date.now() console.log('Starting Apple notarization for', appPath) await notarize({ appPath, appBundleId: APP_BUNDLE_ID, appleId: APPLE_ID, appleIdPassword: APPLE_APP_SPECIFIC_PASSWORD, teamId: APPLE_TEAM_ID }) console.log('Finished Apple notarization for', appPath, `in ${(Date.now() - now) / 1000}s`) } module.exports = main

关键点说明：

• 凭证来源：APPLE_ID、APPLE_APP_SPECIFIC_PASSWORD、APPLE_TEAM_ID三个环境变量来自.env文件（脚本开头require('dotenv').config()）；
• 跳过机制：任意凭证缺失或非 macOS 平台都会跳过公证并打印日志，不会阻断构建；
• Bundle ID：与 electron-builder.config.ts 中的appId: 'com.molunerfinn.picgo'保持一致。

2.3 构建配置中的签名与公证配套

在 electron-builder.config.ts 的mac段可以看到完整的签名/公证配套参数：

mac: { icon: 'build/icons/icon.icns', extendInfo: { LSUIElement: 0 }, target: [ { target: 'dmg', arch: ['arm64', 'x64'] } ], artifactName: 'PicGo-${version}-${arch}.${ext}', hardenedRuntime: true, entitlements: 'build/entitlements.mac.plist', entitlementsInherit: 'build/entitlements.mac.plist', notarize: false }

• hardenedRuntime: true：开启 macOS 强化运行时（Hardened Runtime），这是通过 Apple 公证的必要前提；
• entitlements/entitlementsInherit：指向build/entitlements.mac.plist，声明应用所需的权限白名单；
• notarize: false：electron-builder 内置公证被关闭，改由afterSign钩子执行自定义公证脚本。

afterSign钩子的启用逻辑在配置顶部：

const shouldNotarize = process.env.SKIP_NOTARIZE !== 'true' const config: Configuration = { appId: 'com.molunerfinn.picgo', productName: 'PicGo', afterSign: shouldNotarize ? 'scripts/notarize.js' : undefined, // ... }

也就是说，构建时可通过设置SKIP_NOTARIZE=true环境变量临时关闭公证（例如本地调试时）。构建产物为PicGo-${version}-${arch}.dmg，同时覆盖arm64与x64两种架构。

三、图床配置复制按钮与二次确认弹窗

3.1 功能价值

当用户在同一图床服务上维护多套配置时（例如多个 S3 Bucket、多个 GitHub 仓库、不同命名空间），手工重复填写字段既繁琐又易错。2.4.2 在「图床配置界面」为配置项新增了复制按钮，可以一键复制已有配置生成新配置，再按需微调即可复用。

3.2 防误操作设计

同时，为规避误触导致的配置丢失，复制与删除操作均增加了二次确认弹窗：

• 复制配置前弹出确认对话框，明确告知将基于当前配置创建副本；
• 删除配置前弹出确认对话框，用户需确认后才真正删除。

这一交互层面的防御性设计，显著降低了多配置管理场景下的误操作成本。

四、通知系统重构与notificationSound设置

4.1 配置项定义

notificationSound是本次新增的布尔型设置，用于控制上传结果通知是否播放声音。它在设置面板的「上传工作流」分组中作为独立开关出现，渲染逻辑位于 settings-section-upload-workflow.tsx：

<SettingsRow hidden={!isItemVisible("notification-sound")} title={t("SETTINGS_NOTIFICATION_SOUND")} control={ <Switch checked={settingsConfig.notificationSound} onCheckedChange={(checked) => { saveSettingsConfig("settings.notificationSound", checked) }} /> } />

4.2 默认值与类型定义

其类型与默认值定义在 src/renderer/components/main/settings/utils.ts 与同文件第 323 行附近：

// SettingsConfigState 接口中的字段 notificationSound: boolean // defaultSettingsConfig 中的默认值 notificationSound: true,

即默认开启声音提示，用户可在设置中关闭。

4.3 底层生效链路

设置项真正作用于系统通知的地方在 src/main/utils/common.ts 的showNotification函数：

const silent = picgo.getConfig('settings.notificationSound') === false const notification = new Notification({ title, body, silent })

核心逻辑：从全局配置中读取settings.notificationSound，仅当其严格等于false时才将silent置为true，从而静音通知。这一读取方式对旧版本配置文件天然兼容——历史配置中不存在该字段时，读取结果为undefined，不会命中静音分支，行为与旧版一致。

同时，渲染进程在 hydration 阶段会通过 src/renderer/store/utils.ts 的normalizeSettingsConfig对读取值做归一化处理：

notificationSound: normalizeBoolean( rawSettings.notificationSound, defaultSettingsConfig.notificationSound )

即从配置文件中读取到非布尔值（或缺失）时，回退到默认值true，保证状态的一致性和健壮性。相关测试断言可在 src/tests/renderer/store/settings.spec.ts 等测试文件中找到。

五、Bug 修复：两处视觉效果修正

5.1 macOS 26 下 App 图标过大

2.4.2 修复了在 macOS 26 系统下 App 图标渲染过大的问题。该问题源于新版系统对状态栏/菜单栏图标尺寸的渲染规则变化，PicGo 在 2.4.2 中对图标资源与渲染逻辑做了适配，保证图标在各系统版本下保持正常尺寸。

5.2 托盘图片标题两行截断

修复了托盘窗口（Tray Window）中图片标题过长导致样式被破坏的问题。修复后，托盘内图片标题最多显示两行，超出部分自动截断，避免标题撑破托盘布局。这也与当前仓库中line-clamp-2这类 CSS 工具类（见 plugin-detail-header.tsx 的同类用法）所代表的「多行文本截断」处理思路一致。

六、重构：移除 config store

作为 2.4.2 的收尾工作，本次重构移除了「config store」（对应 issue #1371），将配置相关的存取逻辑收拢到统一的数据流中。

从当前仓库结构可以观察到，配置读取与归一化的职责已集中在 src/renderer/store/utils.ts 的normalizeSettingsConfig（含对appearance、autoStart、uploadNotification、notificationSound、logLevel等全部设置项的归一化处理）以及 src/main/utils/common.ts 的主进程读取侧。这意味着：

• 配置的「单一数据源」更加清晰，渲染进程与主进程通过统一的配置读取 API（如picgo.getConfig）访问；
• 移除冗余存储层后，配置读写路径更短，降低了状态不同步的潜在风险。

从源码结构推断，这一重构为后续配置管理相关的功能迭代（如云配置同步等）铺平了道路，但具体演进方向需以官方后续版本为准。

七、升级建议与验证方式

对于正在使用 PicGo 2.4.x 早期版本的用户，升级到 2.4.2 可以立即获得以下收益：

1. macOS 用户：安装包已签名并公证，无需再手动放行，降低首次使用门槛；
2. 多图床配置用户：利用「复制配置」快速派生新配置，配合二次确认防止误删；
3. 安静办公场景：在设置 → 上传工作流中关闭notificationSound，保留通知文案但去除提示音；
4. macOS 26 用户：图标尺寸异常问题得到修复。

验证方式也很简单：在「设置」面板中找到「上传通知声音」开关并切换，上传一张图片后观察通知是否伴随提示音；在图床配置列表中点击复制按钮，确认弹出确认弹窗并生成新配置副本。全部验证无需修改任何源码，仅通过应用界面即可完成。

参考与深入阅读

• 版本更新说明：changelog/2.4.2.md、CHANGELOG.md
• 公证脚本与构建配置：scripts/notarize.js、electron-builder.config.ts
• 通知实现：src/main/utils/common.ts
• 设置项定义与渲染：src/renderer/components/main/settings/utils.ts、settings-section-upload-workflow.tsx
• 配置归一化：src/renderer/store/utils.ts
• 相关测试：src/tests/renderer/store/settings.spec.ts

• 桌面应用
• 开发工具
• 插件系统