狂飙

Spine 插件导致 Unity 打包耗时过长

Sun, 22 Mar 2026 23:29:46 +0800

介绍

打包时需要使用两次 BuildPipeline.BuildPlayer 分别构建不同版本的包，只调用一次则打包时间很正常只有 5 分钟，但是打包两次时间则会膨胀到 30 分钟。

通过阅读分析 Unity 打包日志，发现在两次 BuildPipeline.BuildPlayer 中间有大量长时间耗时的操作呢？实际项目中出现了 1300+ 条类似下面的日志，而且耗时达22分钟：

16:43:08.145856 Unloading 1 Unused Serialized files (Serialized files now loaded: 0)
16:43:09.158184 Unloading 17 unused Assets / (24.7 KB). Loaded Objects now: 38901.
16:43:09.158184 Memory consumption went from 0.72 GB to 0.72 GB.
16:43:09.158184 Total: 960.310500 ms (FindLiveObjects: 2.454500 ms CreateObjectMapping: 3.433300 ms MarkObjects: 954.311900 ms  DeleteObjects: 0.110200 ms)
16:43:09.158184 
16:43:09.158184 Unloading 1 Unused Serialized files (Serialized files now loaded: 0)
16:43:10.170468 Unloading 17 unused Assets / (4.4 KB). Loaded Objects now: 38901.
16:43:10.170468 Memory consumption went from 0.72 GB to 0.72 GB.
16:43:10.170468 Total: 956.463900 ms (FindLiveObjects: 2.442300 ms CreateObjectMapping: 3.146500 ms MarkObjects: 950.779100 ms  DeleteObjects: 0.095300 ms)

...

17:05:10.661445 Unloading 2 Unused Serialized files (Serialized files now loaded: 0)
17:05:11.675348 Unloading 13 unused Assets / (6.2 KB). Loaded Objects now: 40923.
17:05:11.675348 Memory consumption went from 0.71 GB to 0.71 GB.
17:05:11.675348 Total: 891.505800 ms (FindLiveObjects: 2.536600 ms CreateObjectMapping: 3.384700 ms MarkObjects: 885.480900 ms  DeleteObjects: 0.102900 ms)
17:05:11.675348 
17:05:11.675348 Unloading 4 Unused Serialized files (Serialized files now loaded: 0)
17:05:12.688781 Unloading 20 unused Assets / (12.8 KB). Loaded Objects now: 40923.
17:05:12.688781 Memory consumption went from 0.72 GB to 0.72 GB.
17:05:12.688781 Total: 890.204700 ms (FindLiveObjects: 2.589100 ms CreateObjectMapping: 3.347600 ms MarkObjects: 884.123500 ms  DeleteObjects: 0.143700 ms)

环境

Unity 2022.3.62f1
Windows 10 22H2

问题分析

上面的日志是卸载资源，Unity 编辑器下对应的 API 是 EditorUtility.UnloadUnusedAssetsImmediate()

Unity - Scripting API: EditorUtility.UnloadUnusedAssetsImmediate

问题出在 Spine 插件的构建预处理器 SpineBuildProcessor.cs。它作为 IPreprocessBuildWithReport（callbackOrder = -2000）在 BuildPipeline.BuildPlayer 之前执行：

SpineBuildProcessor.cs Lines 73-93

internal static void PreprocessSpinePrefabMeshes () {
    BuildUtilities.IsInSkeletonAssetBuildPreProcessing = true;
    try {
        AssetDatabase.StartAssetEditing();
        prefabsToRestore.Clear();
        var prefabAssets = AssetDatabase.FindAssets("t:Prefab");
        foreach (var asset in prefabAssets) {
            string assetPath = AssetDatabase.GUIDToAssetPath(asset);
            GameObject prefabGameObject = AssetDatabase.LoadAssetAtPath<GameObject>(assetPath);
            if (SpineEditorUtilities.CleanupSpinePrefabMesh(prefabGameObject)) {
                prefabsToRestore.Add(assetPath);
            }
            EditorUtility.UnloadUnusedAssetsImmediate();
        }
        AssetDatabase.StopAssetEditing();
        if (prefabAssets.Length > 0)
            AssetDatabase.SaveAssets();
    } finally {
        BuildUtilities.IsInSkeletonAssetBuildPreProcessing = false;
    }
}

同样的问题也出现在 PreprocessSpriteAtlases 中：

SpineBuildProcessor.cs Lines 111-131

internal static void PreprocessSpriteAtlases () {
    BuildUtilities.IsInSpriteAtlasBuildPreProcessing = true;
    try {
        AssetDatabase.StartAssetEditing();
        spriteAtlasTexturesToRestore.Clear();
        var spriteAtlasAssets = AssetDatabase.FindAssets("t:SpineSpriteAtlasAsset");
        foreach (var asset in spriteAtlasAssets) {
            string assetPath = AssetDatabase.GUIDToAssetPath(asset);
            SpineSpriteAtlasAsset atlasAsset = AssetDatabase.LoadAssetAtPath<SpineSpriteAtlasAsset>(assetPath);
            if (atlasAsset && atlasAsset.materials.Length > 0) {
                spriteAtlasTexturesToRestore[assetPath] = AssetDatabase.GetAssetPath(atlasAsset.materials[0].mainTexture);
                atlasAsset.materials[0].mainTexture = null;
            }
            EditorUtility.UnloadUnusedAssetsImmediate();
        }
        AssetDatabase.StopAssetEditing();
        if (spriteAtlasAssets.Length > 0)
            AssetDatabase.SaveAssets();
    } finally {
        BuildUtilities.IsInSpriteAtlasBuildPreProcessing = false;
    }
}

问题本质

这两个方法的致命问题是：在 foreach 循环的每次迭代内部调用了 EditorUtility.UnloadUnusedAssetsImmediate()。

从日志中可以看到：

指标	值
每次 `MarkObjects` 耗时	~950ms
已加载对象数	38,901 ~ 40,923
每次卸载的资源	仅 13~20 个（几 KB）
循环次数	1,300+ 次（= 项目中 Prefab 总数 + SpineSpriteAtlasAsset 数量）
总耗时	1,300 × ~1s ≈ 22 分钟

每次调用 UnloadUnusedAssetsImmediate() 都需要完整遍历内存中所有 38,901+ 个对象来执行 MarkObjects，但每次只卸载了十几个微小资源（几 KB），内存从 0.72GB 到 0.72GB 几乎没有变化——这完全是无效的重复劳动。

修复方案

修改文件： Assets/Plugins/Spine/Editor/spine-unity/Editor/Utility/SpineBuildProcessor.cs

两处改动：将 EditorUtility.UnloadUnusedAssetsImmediate() 从 foreach 循环内部移到循环结束后（StopAssetEditing 之后）只调用一次。

	修改前	修改后
`PreprocessSpinePrefabMeshes`	循环内每个 Prefab 都调用一次	循环外只调用一次
`PreprocessSpriteAtlases`	循环内每个 Atlas 都调用一次	循环外只调用一次
预估耗时	1,300+ 次 × ~1s = 22 分钟	1 次 × ~1s = 1 秒

这个修复将这部分构建时间从 22 分钟压缩到约 1 秒。UnloadUnusedAssetsImmediate 的目的是防止循环中加载大量 Prefab 导致内存溢出，但每次循环只加载一个 Prefab 然后立即卸载是极其低效的做法——在循环结束后统一清理一次就足够了。

官方现状

截止到 2026-03-22 最新的 Spine 4.2 版本依然存在此问题

spine-runtimes/spine-unity/Assets/Spine/Editor/spine-unity/Editor/Utility/SpineBuildProcessor.cs at 4.2 · EsotericSoftware/spine-runtimes · GitHub

Unity 测量游戏启动时间

Sun, 08 Feb 2026 23:49:58 +0800

介绍

测量游戏启动时间，用于性能优化，需要量化这个数值。

环境

Unity 2022.3.62f1
Windows 10 22H2

启动时间总览

操作系统加载应用程序
应用程序进入 main 入口
Unity 初始化完成
启动游戏

从日志获取启动时间

可以将 Android Logcat 获取到日志中的绝对时间改成相对时间，以第一条日志为基准。

使用 Python 3 来编写这个小工具。convert_to_relative_time.py

#!/usr/bin/env python3
"""将 Android Logcat 日志的时间戳转换为相对时间"""

import re
import sys
from datetime import datetime

TIMESTAMP_PATTERN = re.compile(r'^(\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2}\.\d{3}) \d+-\d+/\S+ ')
TIMESTAMP_FORMAT = '%Y-%m-%d %H:%M:%S.%f'


def parse_timestamp(ts_str):
    """解析时间戳字符串"""
    return datetime.strptime(ts_str, TIMESTAMP_FORMAT)


def format_relative_time(delta):
    """将时间差格式化为 +HH:MM:SS.mmm 格式"""
    total_seconds = delta.total_seconds()
    hours, remainder = divmod(total_seconds, 3600)
    minutes, seconds = divmod(remainder, 60)
    milliseconds = int((seconds - int(seconds)) * 1000)
    return f"+{int(hours):02d}:{int(minutes):02d}:{int(seconds):02d}.{milliseconds:03d}"


def convert_log_file(input_file, output_file=None):
    """转换日志文件中的时间戳为相对时间"""
    if output_file is None:
        output_file = input_file.rsplit('.', 1)[0] + '-relative.log'

    first_timestamp = None
    output_lines = []

    with open(input_file, 'r', encoding='utf-8') as f:
        for line in f:
            match = TIMESTAMP_PATTERN.match(line)
            if match:
                ts_str = match.group(1)
                current_ts = parse_timestamp(ts_str)

                if first_timestamp is None:
                    first_timestamp = current_ts

                delta = current_ts - first_timestamp
                relative_str = format_relative_time(delta)
                line = relative_str + ' ' + line[match.end():]

            output_lines.append(line)

    with open(output_file, 'w', encoding='utf-8') as f:
        f.writelines(output_lines)

    print(f"转换完成: {output_file}")
    return output_file


if __name__ == '__main__':
    if len(sys.argv) < 2:
        input_file = 'android-logcat.log'
    else:
        input_file = sys.argv[1]

    output_file = sys.argv[2] if len(sys.argv) > 2 else None
    convert_log_file(input_file, output_file)

游戏内测量启动时间

使用 DeepSeek 编写：

Unity 中编写一个测量启动时间的脚本，使用 Time.realtimeSinceStartupAsDouble
接口为 Mark(step) PrintSummary Reset 所有时间均显示为毫秒整数
使用单例而不是MonoBehaviour，不用转换为整数而是在显示时格式化为整数
并不是第一次调用 Mark 才开始计时，所以时间计算不需要减去第一步的时间
同时输出每一步的占比，耗时与占比需要右对齐，步骤名称列的长度需要是最长步骤名称+4
同时增加一列相对上一步的耗时，最后增加一行总用时
占比与增量列交换一下，占比改为相对上一步的占比
占比改为这一步与上一步之间的用时/总用时

结果：

using System;
using System.Collections.Generic;
using System.Linq;
using UnityEngine;

public class StartupTimer
{
    private static readonly StartupTimer instance;
    static StartupTimer() => instance = new StartupTimer();
    private StartupTimer() => steps = new List<Step>();

    public static StartupTimer Instance => instance;

    private struct Step
    {
        public string name;
        public double time; // 秒（从启动开始）
    }
    private List<Step> steps;

    public void Mark(string step) => steps.Add(new Step { name = step, time = Time.realtimeSinceStartupAsDouble });

    public void PrintSummary()
    {
        if (steps.Count == 0)
        {
            Debug.Log("没有记录任何步骤，无法生成总结。");
            return;
        }

        double totalSeconds = steps[^1].time; // 最后一个步骤的绝对时间即为总耗时
        long totalMs = (long)Math.Round(totalSeconds * 1000.0, MidpointRounding.AwayFromZero);

        Debug.Log($"=== 启动时间总结 ===");
        Debug.Log($"总启动耗时: {totalMs} ms\n");

        // 计算最大名称长度（考虑步骤名、表头“步骤名称”和汇总行“总用时”）
        int maxNameLength = steps.Max(s => s.name.Length);
        int nameWidth = Math.Max(maxNameLength, "步骤名称".Length);
        nameWidth = Math.Max(nameWidth, "总用时".Length) + 4;

        // 准备数据列表
        var rows = new List<(string name, long timeMs, long deltaMs, string ratioStr)>();
        long prevTimeMs = 0;
        for (int i = 0; i < steps.Count; i++)
        {
            long timeMs = (long)Math.Round(steps[i].time * 1000.0, MidpointRounding.AwayFromZero);
            long deltaMs = i == 0 ? 0 : timeMs - prevTimeMs;

            // 占比 = 增量 / 总耗时 * 100%
            double ratio = totalMs > 0 ? (deltaMs / (double)totalMs) * 100.0 : 0;
            string ratioStr = ratio.ToString("F1") + "%";

            rows.Add((steps[i].name, timeMs, deltaMs, ratioStr));
            prevTimeMs = timeMs;
        }

        // 表头
        string header = $"{"步骤名称",-nameWidth} {"耗时(ms)",8} {"增量(ms)",8} {"占比",6}";
        Debug.Log(header);

        // 输出每一行
        foreach (var row in rows)
        {
            string line = $"{row.name,-nameWidth} {row.timeMs,8} {row.deltaMs,8} {row.ratioStr,6}";
            Debug.Log(line);
        }

        // 汇总行（总用时）
        Debug.Log(new string('-', header.Length)); // 分隔线
        string totalLine = $"{"总用时",-nameWidth} {totalMs,8} {"",8} {"",6}";
        Debug.Log(totalLine);

        // 步骤间耗时明细（可选）
        if (steps.Count > 1)
        {
            Debug.Log("\n--- 步骤间耗时明细 ---");
            for (int i = 1; i < steps.Count; i++)
            {
                double elapsedSeconds = steps[i].time - steps[i - 1].time;
                Debug.Log($"{steps[i - 1].name} → {steps[i].name}: {FormatMilliseconds(elapsedSeconds)} ms");
            }
        }
    }

    public void Reset() => steps.Clear();

    private string FormatMilliseconds(double seconds)
    {
        long ms = (long)Math.Round(seconds * 1000.0, MidpointRounding.AwayFromZero);
        return ms.ToString();
    }

    // 静态便捷方法
    public static void Mark(string step) => Instance.Mark(step);
    public static void PrintSummary() => Instance.PrintSummary();
    public static void Reset() => Instance.Reset();
}

=== 启动时间总结 ===
总启动耗时: 300 ms

步骤名称                耗时(ms) 增量(ms)    占比
Awake                        50        0    0.0%
Start                       150      100   33.3%
ResourcesLoaded             300      150   50.0%
-----------------------------------------------
总用时                      300

软件推荐：DouK-Downloader

Sun, 01 Feb 2026 23:50:13 +0800

介绍

DouK-Downloader 是一款用于下载抖音 / TikTok 视频的工具。

环境

Windows 11 23H2
DouK-Downloader V5.7

下载

GitHub - JoeanAmier/TikTokDownloader: TikTok 发布/喜欢/合辑/直播/视频/图集/音乐；抖音发布/喜欢/收藏/收藏夹/视频/图集/实况/直播/音乐/合集/评论/账号/搜索/热榜数据采集工具/下载工具

演示

强烈建议通过视频快速了解使用方法。

前往 bilibili 观看演示；前往 YouTube 观看演示

使用

整个工具是一款基于命令行的 TUI 工具，实际使用起来并不比 GUI 的工具差，并且由于减少了 GUI 导致使用起来非常简单。

Text-based user interface - Wikipedia

建议使用自己账号的 Cookie，方便下载到高清的视频。

TikTokDownloader/docs/Cookie获取教程.md at master · JoeanAmier/TikTokDownloader · GitHub

视频

可以方便地下载分享链接中的视频，如果通过其他方式保存下来的分享链接，可以批量下载。

用户

可以通过修改 _internal/Volume/settings.json 增加用户信息，后续可以定时批量下载用户发布的视频。

软件推荐：SourceGit 客户端

Sun, 14 Dec 2025 23:47:30 +0800

介绍

SourceGit 是一款跨平台、开源的 Git GUI 客户端，支持 Windows、macOS、Linux。

SourceGit - Opensource & Free Git Gui Client

环境

Windows 22H2
SourceGit 2025.39

下载安装

Releases · sourcegit-scm/sourcegit

将压缩包的内容直接解压到 %LOCALAPPDATA%\Programs 中，推荐使用软件推荐：Bandizip - 狂飙解压。

使用

进入后可以切换为中文界面。

与 Fork 比较

优点

开源
跨平台
完全使用 C# 进行开发
界面与功能都非常像 Fork

缺点

缺少 Lean Branching ⭐️ Lean Branching - a git branching model to keep clean history · Issue #1432 · fork-dev/TrackerWin
缺少 pull –rebase 前后的自动 stash push 与 stash pop 操作

虽然现阶段功能没有 Fork 那么全，例如，但由于软件是开源的，相信未来这些功能都会有。

软件推荐：Git 客户端 Fork - 狂飙

建议将其作为备选，等待其成熟后引入到团队中使用。

Unity 6.3 正式发布

Sun, 07 Dec 2025 23:55:49 +0800

介绍

Unity 6.3 LTS 正式发布：

LTS 周期

只有刚刚开始的新项目推荐使用 Unity 6.3 LTS。
旧项目需要升级 Unity 版本则推荐 Unity 6 LTS，经过一年多的维护，Unity 6 LTS 基本上没有什么大 Bug 了。

亮点

Platform Toolkit 提供统一API，简化跨平台功能（如账户、存档、成就）开发。
AssetBundle 的 TypeTree去重：为部分游戏减少97%以上的运行时内存占用。
稳定性提升：回归问题减少30%，用户报告问题减少22%，积压问题处于三年最低水平。
精灵图集分析器：新工具，用于识别图集使用低效问题。
UI系统：UGUI持续改进；UI Toolkit新增可定制着色器、SVG支持。
HTTP/2支持：在UnityWebRequest中默认启用，可降低服务器与设备负载（安卓测试显示服务器负载降低约40%）。
Unity Core Standards：引入经过验证和签名的资源包认证体系，提高第三方工具可靠性。

总结

Unity 6.3 LTS 是一个以稳定支持、卓越性能和生产就绪为核心的版本。它通过统一的跨平台工具链、经过大型游戏验证的显著性能提升、以及对现代图形和工作流的强大支持，旨在让开发团队能够更高效、更自信地开发和运营项目。

Unity 2019 无法删除长路径文件

Sun, 30 Nov 2025 23:30:57 +0800

介绍

在执行 Directory.Delete 删除目录时，目录内部存在过深的子目录而完整路径超过 260 个字符，删除就会出现异常。

DirectoryNotFoundException: Could not find a part of the path "C:\Project\XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX\XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX\Output\GradleProject\launcher\build\intermediates\desugar_graph\release\dexBuilderRelease\out\currentProject\jar_8644da973e7b1e319711ad5b4fbc94027d2acce4dda8b1bd6d51994cb312313d_bucket_0\graph.bin"
  at System.IO.File.Delete (System.String path) [0x00073] in <eae584ce26bc40229c1b1aa476bfa589>:0
  at System.IO.Directory.RecursiveDelete (System.String path) [0x0003f] in <eae584ce26bc40229c1b1aa476bfa589>:0
  at System.IO.Directory.RecursiveDelete (System.String path) [0x00024] in <eae584ce26bc40229c1b1aa476bfa589>:0
  at System.IO.Directory.RecursiveDelete (System.String path) [0x00024] in <eae584ce26bc40229c1b1aa476bfa589>:0
  at System.IO.Directory.RecursiveDelete (System.String path) [0x00024] in <eae584ce26bc40229c1b1aa476bfa589>:0
  at System.IO.Directory.RecursiveDelete (System.String path) [0x00024] in <eae584ce26bc40229c1b1aa476bfa589>:0
  at System.IO.Directory.RecursiveDelete (System.String path) [0x00024] in <eae584ce26bc40229c1b1aa476bfa589>:0
  at System.IO.Directory.RecursiveDelete (System.String path) [0x00024] in <eae584ce26bc40229c1b1aa476bfa589>:0
  at System.IO.Directory.RecursiveDelete (System.String path) [0x00024] in <eae584ce26bc40229c1b1aa476bfa589>:0
  at System.IO.Directory.RecursiveDelete (System.String path) [0x00024] in <eae584ce26bc40229c1b1aa476bfa589>:0
  at System.IO.Directory.RecursiveDelete (System.String path) [0x00024] in <eae584ce26bc40229c1b1aa476bfa589>:0
  at System.IO.Directory.Delete (System.String path, System.Boolean recursive) [0x00009] in <eae584ce26bc40229c1b1aa476bfa589>:0
  at Build.Export () [0x0008d] in C:\Project\XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX\XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX\Build.cs:291

环境

Windows 10 21H2
Unity 2019.4.41f1

分析

虽然传入的路径没有那么长，但是在 Directory.Delete 内部会使用递归删除子目录与子文件，导致路径超过 260 个字符限制。

Windows 启用长路径支持无效，使用 \?\ 前缀无效

- 文件命名、路径和命名空间 - Win32 apps | Microsoft Learn

本质原因是因为路径过长，Unity 内置 mono 系统库版本过老，无法删除长路径。

- mono/mcs/class/referencesource/mscorlib/system/io/directory.cs at main · mono/mono · GitHub

方案

Unity 2019

推荐使用外部工具删除目录，例如 rmdir 命令。

Unity 升级

实测 Unity 2022.3.62f1 没有这个问题，相同环境下相同代码可以正常删除。

推荐旧项目尽可能升级到最新的 LTS 版本。

.NET 10 LTS 正式发布

Sun, 16 Nov 2025 23:53:02 +0800

介绍

.NET 10 LTS 正式发布

Download .NET 10.0 (Linux, macOS, and Windows) | .NET

长期支持

.NET 10 是 .NET 9 的继任者，作为长期支持（LTS）版本，支持三年。

.NET 10 中的新增功能 | Microsoft Learn

C# 14

C# 14 引入了多项新功能和增强功能，以提高开发人员的工作效率和代码质量。关键更新包括：

基于字段的属性为从自动实现属性到编写自定义 get 和 set 访问器提供了一条更流畅的路径。可以使用上下文关键字访问编译器生成的后盾字段 field 。
表达式 nameof 现在支持未绑定的泛型类型，例如 List<>，它返回类型的名称而无需类型参数。
对 Span<T> 和 ReadOnlySpan<T> 的隐式转换提供一流支持。
参数修饰符（例如 ref、in 或 out）在 lambda 表达式中允许使用，并且无需指定参数类型。
支持部分实例构造函数和部分事件，补充 C# 13 中引入的部分方法和属性。
新 extension 块添加了对静态扩展方法的支持，以及静态和实例扩展属性。
使用 ?. 运算符的 Null 条件赋值。
用户定义的复合赋值运算符，如 += 和 -=。
用户定义的增量（++）和递减（--）运算符。

有关详细信息，请参阅 C# 14 中的新增功能。

Rider

Rider 2025.3 可以对 .NET 10 提供发布当日支持，包括 C# 14 中的扩展成员、扩展运算符和用户自定义复合赋值运算符等功能，同时通过更新确保与最新编译器更改保持一致。此版本还带来了对 Unity、Unreal Engine 和 Godot 游戏开发的扩展支持，将 Islands 主题设为 JetBrains IDE 的全新默认外观，并提升了解决方案启动的性能。

Rider 最新变化

下载

其他版本 - Rider

Windows 迁移到另一块硬盘

Sun, 26 Oct 2025 23:08:45 +0800

介绍

系统盘满了不想要重装，需要将系统迁移到大的硬盘上。

DiskGenius软件，提供了系统迁移功能，使用DiskGenius,可以方便的把系统迁移到SSD固态硬盘，或其他存储设备中去，免去了重新安装系统、驱动、软件及复制数据等工作，非常方便！

迁移Windows系统到ssd固态硬盘或其他硬盘，DiskGenius特色功能介绍

环境

Windows 10 22H2
DiskGenius V5.6.0.1565 x64

操作过程

如果要迁移到的硬盘上还有数据，需要提前将其转移到其他硬盘。

推荐将所有数据拷贝到另一个硬盘中，然后格式化，因为剪切会在拷贝完成后删除原有文件，而直接拷贝没有删除的话则无需处理可能存在的文件占用、符号链接等导致无法删除的问题。

另外可以在晚上拷贝，第二天格式化，一晚上的时间足够拷贝所有文件。

迁移

另外，如果用户的电脑比较新，支持UEFI启动，那么在系统迁移窗口中，可以直接指定系统迁移完成后，需要不需要更改启动项，是否需要从迁移后的目标硬盘中的系统启动。省去了用户自己在Bios中手工更改启动项的步骤

按照文档操作即可，注意可以勾选修改启动盘符。

最新版本的DiskGenius，对硬盘的备份还原等操作，做了大幅度的优化，极大的提升了相关操作的速度。得益于此，DiskGenius系统迁移的速度非常快，根据笔者的测试，一般的Windows 系统，包括Win10、Win8、Win7等，数据量不大的情况下，系统迁移的时间不超过10分钟，选择热迁移模式，还不影响电脑的正常使用！

实测有效，256G 固态硬盘 18分钟完成迁移。

注意事项

虽然 DiskGenius 推荐使用热迁移模式，但是为了数据安全建议使用重启到WinPE模式。
迁移系统后，推荐在管理中直接删除原系统的盘符，保留原系统硬盘一段时间，防止有任何问题可以及时回退。

Unity CVE-2025-59489 漏洞

Sun, 19 Oct 2025 23:57:01 +0800

介绍

An important message

A security vulnerability was identified that affects games and applications built on Unity versions 2017.1 and later for Android, Windows, Linux, and macOS operating systems. There is no evidence of any exploitation of the vulnerability, nor has there been any impact on users or customers. We have proactively provided fixes that address the vulnerability, and they are already available to all developers. The vulnerability was responsibly reported by the security researcher RyotaK, and we thank him for working with us.

Games and applications already built:

We strongly recommend you download the patched update for your version of the Unity Editor, recompile, and republish your application.

We have provided a tool to patch already-built applications dating back to 2017.1 for Android, Windows, and macOS for developers who prefer not to rebuild their projects. The tool can be accessed here.

Unity Platform Protection: Take Immediate Action to Protect Your Games and Apps - CVE Q&A - Unity Discussions

简单说就是 Unity CVE-2025-59489 漏洞影响了从 Unity 2017.1 到现在的所有版本，因此需要重新构建所有已发布的游戏才可以修复漏洞。

推荐通过以下官方说明页面详细了解具体问题及对应方案：

Unity Security Vulnerability:Developer Remediation Guide

环境

Windows 10 22H2
Unity 2019.4.41f1
Unity 2022.3.62f1

代理服务器

截止到 2025-10-19，由于 Unity 中国强制下载链接跳转到特供版，因此必须使用美国代理服务器才能下载。

以下所有方法的前提是配置好这个美国代理服务器。

在线安装 Unity

在线安装优点

Unity 虽然在每个版本的页面中都提供了相关的组件下载，但是相对于 Unity Hub 在线安装，缺少了关键的 Android SDK、NDK、JDK。

由于不同 Unity 版本使用了不同的Android SDK、NDK、JDK，想要自己处理太过于麻烦。

Unity Hub 内部存储有每个版本对应的 Android SDK、NDK、JDK 版本下载地址并且会自动安装，使用起来极为方便。

代理 Unity Hub

代理模式

网络问题 - Unity 2019.4 - Unity 手册

使用 CMD 运行以下命令，设置代理服务器启动 Unity Hub。

1
2
3

set HTTP_PROXY=http://127.0.0.1:7897
set HTTPS_PROXY=http://127.0.0.1:7897
start "" "C:\Program Files\Unity Hub\Unity Hub.exe"

代理服务器在其他机器上时可以修改上面的 IP 部分。

TUN 模式

直接打开代理软件的 TUN 模式，然后运行 Unity Hub。

如何逃离Unity中国特供版 | Logiconsole

代理 Unity 版本下载页面

使用美国服务器代理打开下载页面链接，不然页面会自动跳转到 Unity 中国。

Download Archive - Unity

点击 Install 按钮通过 unityhub:// 协议链接进行安装，稍等片刻后 Unity Hub 就会弹出对应的组件选择页面。

在网络不好的情况下，安装时推荐优先编辑器，这样不会因为网络中断导致整个安装全部失败，然后再通过 Add Modules 方式顺序安装其他所有需要的组件。

实测

通过在线安装了 Unity 2019.4.41f1 与 Unity 2022.3.62f2，可以正常使用。

离线安装 Unity

我认为最好的方式是在一台可以在线安装的机器上安装好 Unity，然后将整个 Unity 安装目录打包拷贝到需要的机器上。

如果担心 Unity 安装程序安装了对应的运行时库，那么可以下载 Unity 编辑器的安装包先安装一次，然后再将整个 Unity 安装目录拷贝并覆盖现有的 Unity 安装目录。

组件下载方法

Chrome 默认不支持断点续传，由于文件过大可能在下载过程中经常中断，因此推荐使用支持断点自动续传的 FDM 下载，设置为手动使用代理，确保下载到的链接域名是 unity3d.com，否则就会下载到 unity3d.cn 中国特供版。

Free Download Manager - 從網路下載任何東西

FDM 本身有数字签名，而且支持只为当前用户安装，安装过程不需要管理员权限，有中文界面、跨平台支持 Windows macOS Linux。

补丁方法

由于需要在已发布的程序上打补丁，因此比较麻烦，只建议手动处理。

如果项目支持自动打包，建议升级 Unity，而不是增加一步打补丁的步骤。由于打补丁需要替换文件后重新签名，所以比较消耗时间。

CVE-2025-59489 Patcher Tool - CVE Q&A - Unity Discussions

Android SDK buildtools 问题

使用 Unity 2019.4.41f1 手动打包 Android 时会弹出提示：

Detected outdated SDK Build Tools version 28.0.3 when the min version is 29.0.2 UnityException: SDK Build Tools version 28.0.3 < 29.0.2. Note: when building with Gradle, “Use Highest Installed” option will update SDK Build Tools as well.

Update Android SDK Use Highest Installed Cancel

在这个弹窗处如果点击了 Update Android SDK 或 Use Highest Installed 按钮，Unity 会记住这个行为，不会在后续的命令行运行中提示以下错误。

使用命令行打包时会提示：

Detected outdated SDK Build Tools version 28.0.3 when the min version is 29.0.2 UnauthorizedAccessException: Access to the path “C:/Program Files/Unity/Hub/Editor/2019.4.41f1/Editor/Data/PlaybackEngines/AndroidPlayer\SDK\tempToolsDir” is denied.

使用管理员运行 Android Studio，在 Settings 中 SDK 页面：

首先切换 SDK 目录到 C:/Program Files/Unity/Hub/Editor/2019.4.41f1/Editor/Data/PlaybackEngines/AndroidPlayer\SDK\
切换完成后返回 SDK 页面，手动选择 BuildTools 29.0.2 安装，必须是这个版本，即使有更高的版本 Unity 运行时只会检查这个版本。
Unity 命令行运行打包。

如果不安装这个版本，只能手动打一次 Android 包，在弹出前面的提示时点击 Update Android SDK 或 Use Highest Installed 按钮，后续就不会有问题了。

软件推荐：重复文件查找 DoubleKiller

Sun, 14 Sep 2025 23:08:45 +0800

介绍

DoubleKiller 是一款针对个人用户免费使用，在 Windows 上查找并删除重复文件的小工具。基于文件名、尺寸、日期、CRC32 校验四种方式相互结合完成重复文件的查找与删除。@Appinn

功能

默认是基于大小与 CRC32 条件判断文件是否相同，可以根据需要修改条件组合。

扫描完成后支持复制结果。

结合 AI 使用

推荐使用 DeepSeek | 深度求索等 AI 工具帮忙编写代码，例如可以将一小部分结果直接给 AI，然后描述如何处理重复文件。

尝试过删除 Unity 项目中的重复资源，将所有重复资源的引用修改为第一个资源，AI 给出的 C# 代码可以正常使用。

狂飙

Spine 插件导致 Unity 打包耗时过长

介绍

环境

问题分析

问题本质

修复方案

官方现状

Unity 测量游戏启动时间

介绍

环境

启动时间总览

从日志获取启动时间

游戏内测量启动时间

软件推荐：DouK-Downloader

介绍

环境

下载

演示

使用

配置 Cookie

视频

用户

软件推荐：SourceGit 客户端

介绍

环境

下载安装

使用

与 Fork 比较

优点

缺点

Unity 6.3 正式发布

介绍

LTS 周期

亮点

总结

Unity 2019 无法删除长路径文件

介绍

环境

分析

方案

Unity 2019

Unity 升级

.NET 10 LTS 正式发布

介绍

长期支持

C# 14

Rider

下载

Windows 迁移到另一块硬盘

介绍

环境

操作过程

迁移

注意事项

Unity CVE-2025-59489 漏洞

介绍

环境

代理服务器

在线安装 Unity

在线安装优点

代理 Unity Hub

代理模式

TUN 模式

代理 Unity 版本下载页面

实测

离线安装 Unity

组件下载方法

补丁方法

Android SDK buildtools 问题

软件推荐：重复文件查找 DoubleKiller

介绍

功能

结合 AI 使用