fix(updater): run refreshUpgradeDeliveryService asynchronously to avoid blocking initialization

[qiuzhiqian]

Bug: https://pms.uniontech.com/bug-view-364311.html

[github-actions]

CLA Assistant Lite bot:
提交邮箱中包含我们的合作伙伴，但您似乎并非合作伙伴的成员或对接人，请联系相关对接人将您添加至组织之中，或由其重新发起 Pull Request。
The commit email domain belongs to one of our partners, but it seems you are not yet a member of the current organization, please contact the contact person to add you to the organization or let them submit the Pull Request.

xml seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.
_{You can retrigger this bot by commenting recheck in this Pull Request}

[deepin-ci-robot]

deepin pr auto review

你好！我是CodeGeeX。我已仔细审查了你提供的 Git Diff 内容。

本次修改将 u.refreshUpgradeDeliveryService() 从同步调用改为了异步的协程调用 go u.refreshUpgradeDeliveryService()。下面我将从语法逻辑、代码质量、代码性能和代码安全四个维度为你进行详细的代码审查，并提出改进意见。

1. 语法逻辑

• 潜在的数据竞争：由于 refreshUpgradeDeliveryService 是在独立协程中运行的，如果该方法内部或其调用的子函数对 u（Updater 结构体实例）的非并发安全字段进行了读写操作，而主协程（或其他后续调用的协程）同时也访问了这些字段，就会产生数据竞争，导致程序崩溃或逻辑异常。
• 初始化时序问题：原本同步调用时，NewUpdater 返回前，refreshUpgradeDeliveryService 一定已经执行完毕。改为异步后，NewUpdater 立即返回，该刷新逻辑可能在后续很久才执行完。如果调用方在拿到 Updater 对象后，立刻依赖该刷新逻辑的结果，可能会遇到未初始化完成的状态。

2. 代码质量

• 错误处理丢失：从上下文看，NewUpdater 中前一行 if err != nil { logger.Warning(err) } 表明项目有记录错误日志的习惯。如果 refreshUpgradeDeliveryService 内部有返回 error，使用 go 关键字启动协程后，其返回值（包括 error）会被直接丢弃。如果执行失败，可能没有任何日志记录，增加了排查问题的难度。
• 协程生命周期不可控：直接 go 出去的协程属于“野协程”，外部无法得知它何时结束，也无法对其进行优雅的取消或等待。

3. 代码性能

• 正面影响：将可能耗时的网络请求或 I/O 操作放入协程，可以加快 NewUpdater 的初始化速度，减少阻塞，这是性能上的优化。
• 负面影响：如果 refreshUpgradeDeliveryService 涉及到对共享资源的频繁加锁，异步执行可能会增加锁争用的概率，反而影响主流程的性能。

4. 代码安全

• 协程泄漏：如果 refreshUpgradeDeliveryService 内部有长时间阻塞的操作（如 HTTP 请求无超时、等待 Channel 等），这个协程可能会永久阻塞，导致协程泄漏（Goroutine Leak），随着服务运行时间增长，内存占用会持续上升，最终可能导致 OOM。
• Panic 崩溃：在 Go 语言中，如果在一个协程中发生了 Panic 且没有 recover，会导致整个进程崩溃。原本同步调用时，Panic 会向上抛出并被调用方感知，但改为 go 之后，必须确保 refreshUpgradeDeliveryService 内部有 recover 机制，否则极易因未知 Panic 导致服务宕机。

---

💡 改进建议与代码示例

为了解决上述潜在问题，建议对代码进行如下改进：

1. 增加 Panic Recovery：防止异步协程 Panic 导致整个程序崩溃。
2. 保留日志记录：如果函数返回 error，确保在协程内也能记录日志。
3. 增加 Context 控制：传入 context.Context，使得协程支持超时控制和优雅退出。
4. 确保并发安全：检查 refreshUpgradeDeliveryService 内部逻辑，确保对 u 的字段访问是并发安全的。

改进后的代码示例：

// 包装一层，增加 panic recovery 和日志记录
go func() {
    defer func() {
        if r := recover(); r != nil {
            // 记录 panic 堆栈，防止整个进程崩溃
            logger.Errorf("refreshUpgradeDeliveryService panicked: %v\n%s", r, debug.Stack())
        }
    }()

    if err := u.refreshUpgradeDeliveryService(); err != nil {
        // 确保异步执行时的错误也能被记录
        logger.Warning(err)
    }
}()

如果项目使用了 Context（更推荐的做法）：

// 假设 Manager 或 Config 中包含 ctx context.Context
go func() {
    defer func() {
        if r := recover(); r != nil {
            logger.Errorf("refreshUpgradeDeliveryService panicked: %v\n%s", r, debug.Stack())
        }
    }()

    // 传入 context 以支持超时和取消
    if err := u.refreshUpgradeDeliveryService(u.ctx); err != nil && !errors.Is(err, context.Canceled) {
        logger.Warning(err)
    }
}()

总结：将同步调用改为异步协程是一个常见的性能优化手段，但必须配套完善错误处理、Panic 捕获和生命周期管理，否则会为系统埋下严重的稳定性隐患。请务必检查 refreshUpgradeDeliveryService 的内部实现，确保它是并发安全且不会无限阻塞的。

[deepin-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: qiuzhiqian, zhaohuiw42

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• debian/deepin/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment