企业官网建设流程全解析

做 Unity 项目做到一定年头，你会发现一个挺有意思的现象：真正花在写玩法逻辑上的时间，远没有想象中多。大量精力被"新建脚本、改类名、补命名空间、选择继承基类、拖到物体上"这套循环动作吃掉了，一天下来建了十几个脚本，代码行数可能还没超过两百。这活儿不难，但重复，而且极易出错——类名忘了改、文件名和类名对不上、脚本生成到了 Editor 目录导致运行时报空、命名空间拼错带来一屏红字。这也是我后来动手做一套Unity Editor编辑器扩展之创建脚本工具的起因：把"创建脚本"这个动作从手工活变成一条菜单命令，点一下，模板、命名空间、基类、目录、甚至连挂载都给你办妥。

这套东西本质上属于编辑器扩展的一个细分场景，规模不大，但覆盖面很广——小到独立开发者日常提效，大到团队统一脚本规范、统一代码风格、统一目录结构，都能用得上。它解决的核心问题就一句话：把"人肉重复劳动"换成"程序按模板生成"。适合谁看？写过一点 C# 脚本、能看懂using UnityEditor、知道 Inspector 面板里那些东西大概在哪的 Unity 使用者就够起步；如果你已经写过自定义 Inspector 或简单的编辑器窗口，这篇文章里关于刷新时机、域重载、编译等待的部分应该会让你少踩几个坑。

1. 为什么值得为"创建脚本"单独做一个编辑器扩展

1.1 手动创建脚本的隐性成本，比你想的高

很多人觉得新建脚本就两秒的事，右键 → Create → C# Script → 改名字 → 双击打开 → 改类名 → 保存。听起来很快，但一次完整的动作链条其实有七八步，而且每一步都有出错概率。我统计过自己一周的操作：平均每天新建 6 到 10 个脚本，其中有大概两三次会出现"文件名和类名不一致"导致MonoBehaviour挂不上去，或者新脚本被 Unity 默认丢到了 Project 窗口当前选中的目录——而那个目录往往是我刚点过的一个无关文件夹，等发现的时候脚本已经在错误的位置躺了半天。

更麻烦的是规范层面。团队里如果约定"所有运行时脚本必须带Game.Runtime.XXX命名空间"、"所有 UI 相关脚本必须继承自定义基类UIBase"，那么手工创建就变成了一场记忆测试。新人来了记不住，老人来了嫌麻烦直接跳过，等 Code Review 的时候才发现一堆裸脚本，改起来成本翻好几倍。

注意：这类"小工具"最容易犯的错是追求一次性做大做全，结果写了两千行没人用。我的建议是先解决一个最痛的点——通常是"创建时自动带上命名空间和基类"——剩下的以后再说。

从投入产出比看，这套扩展一次写完大概两三百行代码，之后整个项目周期都在受益。而且它是个很好的编辑器扩展入门练手项目：涉及MenuItem、EditorWindow、AssetDatabase、ProjectWindowUtil、Undo这些核心 API，但逻辑复杂度不高，失败了也就是生成个空文件，不会把项目搞坏。

1.2 划清边界：哪些该自动化，哪些不该碰

做这种工具最容易上头的地方，是忍不住把"脚本内容生成"做成一个迷你代码生成器。我见过有人试图根据字段定义自动生成Awake、Start、Update骨架，甚至连GetComponent缓存都给你自动写好。想法很好，实际用起来很别扭——因为一旦生成完你还是要改动，而改完之后模板再更新就会和已有代码打架。

我的判断标准很简单：只自动化"每次都必须一样"的部分，不碰"每个脚本都会不一样"的部分。

• 该自动化的：文件名与类名同步、命名空间声明、using头部、基类继承、目录选择、.meta生成、程序集归属。
• 不该自动化的：具体字段、方法体、生命周期逻辑、业务代码结构。

按这个边界划下来，工具的核心其实就是"模板字符串替换 + 文件写入 + 资产导入"三件事，剩下的都是体验优化。思路清楚了，代码就不会跑偏。

1.3 和 Unity 自带模板的关系：不是替代，是接管入口

Unity 自带有一套脚本模板，位置在编辑器安装目录的Resources/ScriptTemplates下，文件名形如81-C# Script-NewBehaviourScript.cs.txt。你在 Project 窗口右键新建 C# Script 时，Unity 就是拿这个文件做替换，把#SCRIPTNAME#换成你输入的文件名。

所以做自定义脚本创建工具，有两条路：

我选第二条路。原因很直接：官方模板放在安装目录，属于"本机配置"，天然不适合团队协作。自建入口则可以把模板文件一起提交到版本库，谁拉下来都能用同一套规范。这个选择后来被验证是对的——中间换过一次开发机，自建工具开箱即用，官方模板的改动早没了。

2. 方案选型：三种入口形态怎么挑

2.1 MenuItem、EditorWindow、ProjectWindowUtil 右键，各管一段

做脚本创建工具，入口形态基本就三种，它们的定位完全不同，千万别混着用。

第一种是MenuItem，也就是顶部菜单栏或者右键菜单里的一条命令。它的特点是"一键直达"，适合固定参数的场景，比如"创建一个空的 MonoBehaviour"这种没有任何选项的操作。写法就是给静态方法打上[MenuItem("路径")]标签，路径决定了它出现在哪：

• "Assets/Create/..."会出现在 Project 窗口右键的 Create 子菜单里，跟 Unity 自带的创建项排在一起，最符合直觉。
• "Assets/..."出现在 Project 窗口右键的顶层菜单。
• "GameObject/..."出现在 Hierarchy 窗口右键菜单，适合做"创建并挂载"的合并操作。
• "Tools/..."出现在顶部菜单栏，适合放低频但重要的工具。

第二种是EditorWindow，一个独立窗口。它适合参数多的场景：脚本名、命名空间、模板类型、输出目录、是否挂载到选中物体，五六个选项用菜单项根本表达不了。窗口的代价是多一步操作，但换来的是灵活性。

第三种是ProjectWindowUtil系列的静态方法，它本身不是入口，而是"创建资产"的底层能力。ProjectWindowUtil.CreateScriptAssetFromTemplateFile(templatePath, defaultName)这个方法会把模板文件内容读出来、替换占位符、写入目标目录、触发导入，一整套流程给你做完。它的关键优势是自动处理.meta文件和资源导入，比自己File.WriteAllText靠谱得多。

我的实际组合是：菜单项负责高频无参场景，窗口负责需要配置的场景，两者底层都调ProjectWindowUtil。

2.2 为什么优先用 ProjectWindowUtil 而不是直接写文件

刚上手的人第一反应通常是File.WriteAllText(path, content)，然后AssetDatabase.Refresh()。这么写能跑，但坑不少。

第一条坑是.meta文件。Unity 里每个资产都有对应的.meta，里面存着 GUID。自己写文件再刷新，Unity 会自动补.meta，但如果写入和刷新之间有别的逻辑依赖这个脚本（比如立刻LoadAssetAtPath），就会拿不到。ProjectWindowUtil.CreateScriptAssetFromTemplateFile内部走的是编辑器正规的资产创建流程，.meta生成和导入是一体的，时序上更安全。

第二条坑是 Undo 和选中状态。用ProjectWindowUtil创建完，Unity 会自动选中新生成的资产，并进入重命名状态——这个体验跟自己写文件完全不一样，后者创建完你还得自己去 Project 窗口里找。

第三条坑是路径推断。ProjectWindowUtil系列方法会自动以"当前 Project 窗口选中的文件夹"作为默认输出位置，这符合用户直觉。自己实现的话，得用AssetDatabase.GetAssetPath(Selection.activeObject)再判断是文件夹还是文件，逻辑要多写十几行。

提示：ProjectWindowUtil.CreateScriptAssetFromTemplateFile在 Unity 2019.4 LTS 及以后的版本里都能用。更老的版本里叫CreateScriptAsset，签名不一样，如果你的项目要兼容多版本，建议加个版本判断或者干脆只支持 2019.4 以上。

2.3 模板体系的落点：放在哪、叫什么后缀

模板文件放哪，这个问题比想象中重要。我的做法是统一放在Assets/Editor/ScriptTemplates/目录下，文件名形如MonoBehaviourTemplate.txt。

后缀一定要用.txt，不能直接用.cs。原因很实在：Unity 会把.cs文件当脚本编译，而模板里的内容如果带了#SCRIPTNAME#这种占位符，类名根本不存在，编译直接报错。用.txt就不会被编译，Unity 只当它是个普通文本资产。

还有个细节：整个Editor目录里的东西都不会被打进运行时构建，所以模板文件放在这里既安全又不会污染包体。如果模板要给美术、策划看，也可以放到Assets/Editor/ScriptTemplates/README之类的说明文件旁边，方便查阅。

3. 核心 API 拆解：几个必须搞懂的参数和时机

3.1 MenuItem 的路径、优先级与校验方法

MenuItem的路径不只是个字符串，它决定了菜单项的层级和位置。路径用/分隔，最后一段是显示名。优先级（priority）是个整数，控制同层级下的排序，数值小的排前面。Unity 官方约定是：0 到 49 放最顶部，50 到 499 放中间，500 以上放底部。Assets/Create菜单里通常用 1 到 49。

还有一个容易被忽略的用法是校验方法。给MenuItem加第二个参数true，对应的方法就变成校验函数，返回值决定菜单项是否可点击：

[MenuItem("Assets/Create/C# 自定义脚本/MonoBehaviour", false, 100)] private static void CreateMonoBehaviour() { /* ... */ } [MenuItem("Assets/Create/C# 自定义脚本/MonoBehaviour", true, 100)] private static bool CreateMonoBehaviourValidate() { // 只有选中文件夹时才允许创建 return Selection.activeObject is DefaultAsset; }

校验方法的价值在于防止误操作。比如"创建后挂载到选中物体"这种功能，如果当前选中的不是 GameObject，就应该禁用而不是报错。用校验方法把错误挡在入口处，比在方法体里写一堆if判断体验好得多。

3.2 快捷键与路径中的特殊前缀

MenuItem的路径支持快捷键声明，用空格加特殊字符表示：%是 Ctrl（macOS 上是 Cmd），#是 Shift，&是 Alt，_表示无修饰键。比如"Tools/脚本生成器 %#g"就是 Ctrl+Shift+G。

注意：快捷键不要和 Unity 自带的热键冲突，尤其是Ctrl+S、Ctrl+N、Ctrl+Z这些。我吃过一次亏，给一个生成工具绑了Ctrl+N，结果新建场景的功能直接被吃掉，查了半天才反应过来。

路径前缀里还有两个特殊值值得知道："CONTEXT/组件名/方法名"可以给特定组件的右键菜单加项，"Assets/Create/"会自动出现在 Project 窗口的 Create 子菜单。前者用于给自定义组件加扩展操作，后者就是我们这次要用的主力路径。

3.3 AssetDatabase 的刷新时机，是最容易翻车的地方

写完文件之后调不调AssetDatabase.Refresh()，什么时候调，这个问题困扰过很多人。我的经验可以总结成几条：

第一，用ProjectWindowUtil创建资产的话，不需要手动Refresh，它内部已经处理了导入流程。手动再调一次只是浪费性能。

第二，自己用File.WriteAllText写文件的话，必须调AssetDatabase.Refresh()，否则 Unity 根本不知道有新文件。但Refresh是个相对重的操作，它会扫描整个 Assets 目录，所以不要在循环里每个文件调一次，攒完一起调。

第三，如果只是想导入某一个文件，用AssetDatabase.ImportAsset(path, ImportAssetOptions.ForceUpdate)比Refresh精准得多。这个 API 我用了很多次，尤其在批量生成脚本的场景下，先全部写完，再统一ImportAsset，速度明显比逐个Refresh快。

第四，别在ImportAsset之后立刻假设脚本已经编译完成。资源导入和脚本编译是两个不同的阶段，ImportAsset返回时脚本可能还没进编译队列。

3.4 EditorApplication.delayCall：等一帧，世界就不一样了

很多功能"看起来应该能用但就是不行"，根子都在时机上。比如创建完脚本想立刻AddComponent，十有八九会失败，因为脚本虽然写进磁盘了，但还没编译，类型在AppDomain里不存在，GetType返回 null。

EditorApplication.delayCall就是解这个问题的。它把一段委托推迟到下一次编辑器更新时执行，相当于"等这一轮操作走完再说"。典型写法：

string createdPath = "Assets/Scripts/Generated/MyBehaviour.cs"; // ... 创建脚本的代码 ... EditorApplication.delayCall += () => { var script = AssetDatabase.LoadAssetAtPath<MonoScript>(createdPath); if (script == null) return; var type = script.GetClass(); if (type == null) return; // 此时类型已经可用，可以挂载了 };

但要注意，delayCall只延后一帧编辑器更新，如果脚本编译时间较长（比如项目里有一堆代码要重编），一帧不够。更稳的做法是监听CompilationPipeline.compilationFinished事件，或者用EditorApplication.isCompiling配合轮询。我的实际做法是两者结合：先delayCall尝试一次，如果GetClass()返回 null，就挂到编译完成事件上再试。

4. 完整实操：从零搭一个能用的脚本生成器

4.1 目录结构与 Editor 文件夹的分界线

动手之前先把目录定下来，这个顺序不能反。我的结构是这样的：

Assets/ Editor/ ScriptCreators/ ScriptCreatorMenu.cs ScriptGeneratorWindow.cs ScriptTemplateProvider.cs ScriptTemplates/ MonoBehaviourTemplate.txt ScriptableObjectTemplate.txt EmptyClassTemplate.txt InterfaceTemplate.txt Scripts/ Runtime/ Generated/

Assets/Editor/这个目录名是 Unity 的硬性约定，放在里面的脚本会被编进编辑器程序集，只在编辑器环境下存在。这意味着两件事：一是能在里面using UnityEditor而不会影响打包；二是里面的代码不能被运行时脚本引用。

注意：如果你的项目用了 Assembly Definition（.asmdef），Editor目录的规则会被 asmdef 覆盖。这时候要给编辑器脚本单独建一个 asmdef，并在includePlatforms里只勾选Editor。这一点很多人踩过坑，明明放在Editor文件夹里，打包还是报UnityEditor找不到。

4.2 第一步：菜单项版，三十行解决单脚本创建

先做最简版本，跑通整条链路。新建Assets/Editor/ScriptCreators/ScriptCreatorMenu.cs：

using UnityEditor; using UnityEngine; public static class ScriptCreatorMenu { private const string TemplateDir = "Assets/Editor/ScriptTemplates/"; [MenuItem("Assets/Create/C# 自定义脚本/MonoBehaviour 空壳", false, 101)] private static void CreateMonoBehaviour() { string templatePath = TemplateDir + "MonoBehaviourTemplate.txt"; ProjectWindowUtil.CreateScriptAssetFromTemplateFile( templatePath, "NewMonoBehaviour.cs"); } [MenuItem("Assets/Create/C# 自定义脚本/ScriptableObject 空壳", false, 102)] private static void CreateScriptableObject() { string templatePath = TemplateDir + "ScriptableObjectTemplate.txt"; ProjectWindowUtil.CreateScriptAssetFromTemplateFile( templatePath, "NewScriptableObject.cs"); } }

模板文件MonoBehaviourTemplate.txt的内容：

using UnityEngine; namespace Game.Runtime { public class #SCRIPTNAME# : MonoBehaviour { private void Awake() { } private void OnDestroy() { } } }

这里有个关键点：#SCRIPTNAME#是占位符，ProjectWindowUtil.CreateScriptAssetFromTemplateFile会把它替换成你在 Project 窗口里输入的文件名（不含.cs后缀）。所以你输入PlayerController，生成的类名就是PlayerController，文件名和类名天然一致，那个经典的"类名对不上"问题直接被消灭。

默认名"NewMonoBehaviour.cs"会预先填在重命名输入框里并全选，用户直接打字就能覆盖，体验比让他自己从头输入好得多。

4.3 第二步：窗口版，处理需要配置的场景

菜单项解决不了"我要选命名空间、选目录、还要顺手挂到选中物体上"这类需求。这时候上EditorWindow。

using System.IO; using System.Text; using UnityEditor; using UnityEngine; public class ScriptGeneratorWindow : EditorWindow { private enum TemplateKind { MonoBehaviour, ScriptableObject, EmptyClass, Interface } [SerializeField] private string scriptName = "NewBehaviour"; [SerializeField] private string namespaceName = "Game.Runtime"; [SerializeField] private string outputFolder = "Assets/Scripts/Generated"; [SerializeField] private TemplateKind templateKind = TemplateKind.MonoBehaviour; [SerializeField] private bool attachToSelection; [MenuItem("Tools/脚本生成器 %#g")] private static void Open() { var window = GetWindow<ScriptGeneratorWindow>("脚本生成器"); window.minSize = new Vector2(400f, 280f); window.Show(); } private void OnGUI() { EditorGUILayout.LabelField("基础信息", EditorStyles.boldLabel); scriptName = EditorGUILayout.TextField("脚本名", scriptName); namespaceName = EditorGUILayout.TextField("命名空间", namespaceName); templateKind = (TemplateKind)EditorGUILayout.EnumPopup("模板类型", templateKind); EditorGUILayout.Space(); EditorGUILayout.LabelField("输出设置", EditorStyles.boldLabel); outputFolder = EditorGUILayout.TextField("输出目录", outputFolder); attachToSelection = EditorGUILayout.Toggle("创建后挂到选中物体", attachToSelection); EditorGUILayout.Space(); using (new EditorGUI.DisabledScope(!IsNameValid())) { if (GUILayout.Button("生成脚本", GUILayout.Height(34f))) { Generate(); } } } private bool IsNameValid() { return !string.IsNullOrWhiteSpace(scriptName) && !scriptName.Contains(" ") && !File.Exists(Path.Combine(outputFolder, scriptName + ".cs")); } }

这段 GUI 代码里有几个值得说的细节。

[SerializeField]加在窗口字段上，是为了应对域重载。Unity 在脚本编译或进入播放模式时会重载整个AppDomain，窗口对象虽然还在，但普通字段会被重置成默认值。加了[SerializeField]，这些值会被序列化保存，重载之后还能恢复。这个坑我踩过不止一次，窗口开着，编译一下，填好的参数全没了，纯粹是白干。

EditorGUI.DisabledScope用来在名字不合法时把按钮置灰，比点击之后再弹提示温和。判断条件里我加了文件存在性检查，防止覆盖已有脚本——虽然生成器覆盖自己刚写的文件问题不大，但如果目录填错覆盖了核心逻辑脚本，那就不是小事了。

GetWindow<T>会复用已存在的窗口实例，不会每次点菜单都新开一个，这一点比自己new EditorWindow要省心。

4.4 第三步：核心生成逻辑，字符串拼装与文件写入

窗口里那个Generate()方法才是真正干活的部分：

private void Generate() { if (!Directory.Exists(outputFolder)) { Directory.CreateDirectory(outputFolder); } string filePath = Path.Combine(outputFolder, scriptName + ".cs"); string content = BuildContent(); File.WriteAllText(filePath, content, new UTF8Encoding(false)); AssetDatabase.ImportAsset(filePath, ImportAssetOptions.ForceUpdate); AssetDatabase.Refresh(); var createdAsset = AssetDatabase.LoadAssetAtPath<MonoScript>(filePath); Selection.activeObject = createdAsset; EditorGUIUtility.PingObject(createdAsset); if (attachToSelection && templateKind == TemplateKind.MonoBehaviour) { EditorApplication.delayCall += () => TryAttach(filePath); } }

Directory.CreateDirectory顺手处理了目录不存在的情况，不需要在外面单独判断。File.WriteAllText的第三个参数指定new UTF8Encoding(false)，也就是不带 BOM 的 UTF-8。为什么要强调这个？因为有些编辑器、有些 Unity 版本对带 BOM 的文件解析会出现诡异问题，比如文件头部多出一个不可见字符，using语句被识别成非法语句。统一写无 BOM 最稳妥。

ImportAsset和Refresh都调了，看着有点冗余，但实际效果是ImportAsset精准导入这个文件，Refresh兜底扫描一遍确保 Project 窗口立即刷新显示。这点开销可以接受，换来的是用户不会看到"文件生成了但 Project 窗口没显示"的尴尬。

EditorGUIUtility.PingObject会让新生成的脚本在 Project 窗口高亮闪一下，视觉反馈很重要，不然用户根本不知道文件生成到哪里去了。

4.5 模板内容拼装与占位符替换

BuildContent()是字符串拼装的核心，我用的是简单直接的StringBuilder：

private string BuildContent() { var sb = new StringBuilder(); sb.AppendLine("using UnityEngine;"); sb.AppendLine(); bool hasNamespace = !string.IsNullOrWhiteSpace(namespaceName); if (hasNamespace) { sb.AppendLine($"namespace {namespaceName}"); sb.AppendLine("{"); } string indent = hasNamespace ? " " : string.Empty; switch (templateKind) { case TemplateKind.MonoBehaviour: sb.AppendLine($"{indent}public class {scriptName} : MonoBehaviour"); sb.AppendLine($"{indent}{{"); sb.AppendLine($"{indent} private void Awake()"); sb.AppendLine($"{indent} {{"); sb.AppendLine($"{indent} }}"); sb.AppendLine($"{indent}}}"); break; case TemplateKind.ScriptableObject: sb.AppendLine($"{indent}[CreateAssetMenu(fileName = \"{scriptName}\", menuName = \"Config/{scriptName}\")]"); sb.AppendLine($"{indent}public class {scriptName} : ScriptableObject"); sb.AppendLine($"{indent}{{"); sb.AppendLine($"{indent}}}"); break; case TemplateKind.EmptyClass: sb.AppendLine($"{indent}public class {scriptName}"); sb.AppendLine($"{indent}{{"); sb.AppendLine($"{indent}}}"); break; case TemplateKind.Interface: sb.AppendLine($"{indent}public interface I{scriptName}"); sb.AppendLine($"{indent}{{"); sb.AppendLine($"{indent}}}"); break; } if (hasNamespace) { sb.AppendLine("}"); } return sb.ToString(); }

代码看着啰嗦，但它把所有格式细节（缩进、空行、括号位置）都固化下来了，生成结果 100% 一致，不会因为手滑多一个空格导致 StyleCop 之类的检查器报错。这种"固化"在多人协作里价值特别大，代码风格统一不靠口头约定，靠工具保证。

接口那一条我特意加了I前缀，IFooService这种命名是 C# 界的通行做法。如果你团队不用这个约定，把I删掉就行。

4.6 第四步：生成后自动挂载，时机才是难点

TryAttach是整篇文章里最考验时机理解的一段：

private void TryAttach(string scriptPath) { var script = AssetDatabase.LoadAssetAtPath<MonoScript>(scriptPath); if (script == null) return; var type = script.GetClass(); if (type == null) { // 类型还没编译出来，挂到编译完成事件上再试一次 void OnCompilationFinished(object obj) { CompilationPipeline.compilationFinished -= OnCompilationFinished; TryAttach(scriptPath); } CompilationPipeline.compilationFinished += OnCompilationFinished; return; } var selected = Selection.activeGameObject; if (selected == null) return; if (selected.GetComponent(type) != null) { Debug.LogWarning($"{selected.name} 上已经挂载了 {type.Name}"); return; } Undo.AddComponent(selected, type); EditorUtility.SetDirty(selected); }

这段代码里有几个点值得展开。

script.GetClass()返回的是MonoScript里对应的System.Type，如果脚本还没编译完成，它会返回 null。这时候不能硬等，得用事件回调。CompilationPipeline.compilationFinished会在编译结束时触发，但要注意这个事件回调里不能做太重的操作，否则会拖慢编辑器。

Undo.AddComponent而不是selected.AddComponent(type)，这是必须的。前者会注册 Undo 操作，用户按Ctrl+Z能撤销；后者不会，加错了只能手动删除。这种小细节决定了工具是"能用"还是"好用"。

EditorUtility.SetDirty(selected)标记场景对象已修改，配合Undo使用，保证场景保存时改动不丢。

还有一个隐患：如果当前正在 Prefab 编辑模式下，Selection.activeGameObject拿到的是 Prefab 内部的对象，AddComponent会改到 Prefab 上，可能不是用户想要的。稳妥的做法是先判断PrefabStageUtility.GetCurrentPrefabStage()是否为 null，不为 null 时给出提示而不是直接操作。

5. 常见问题与排查技巧实录

5.1 问题速查表

下面这些是我在实际使用和帮别人排查时遇到频率最高的问题，整理成表格方便对照：

5.2 编码问题：中文注释乱码的根源

模板里写中文注释，生成出来变成乱码，这个问题的原因八成是文件编码不是 UTF-8。Windows 下的记事本默认可能存成 ANSI，Unity 读的时候按 UTF-8 解析，中文自然就乱了。

判断方法很简单：用支持编码查看的编辑器打开模板文件，看右下角显示的编码格式。解决方法是统一另存为 UTF-8。另外前面提到的写入时指定new UTF8Encoding(false)，保证输出文件也不带 BOM，两头都对上。

提示：如果团队里有非中文环境的人协作，模板里干脆别写中文注释。这不是妥协，是减少无谓的沟通成本。注释写在提交信息里，或者单独维护一份说明文档，比塞在模板里更合适。

5.3 命名空间与程序集的隐性冲突

生成的脚本如果落在了一个被 asmdef 覆盖的目录里，而这个 asmdef 又没有引用UnityEngine.UI之类的包，那么模板里带的using UnityEngine.UI;就会报编译错误。这个问题在新建项目时特别常见，因为目录结构还没稳定，asmdef 的划分也还在调整。

处理办法有两个。一是生成前检查目标目录的 asmdef 归属，用CompilationPipeline.GetAssemblies()拿到程序集信息，判断目标目录是否被覆盖，如果被覆盖就给出提示。二是干脆在工具里加一个"输出目录"下拉框，列出项目里所有合法目录让用户选，从源头避免填错。

我更倾向于第二个，因为简单直接。下拉框的数据来源可以用AssetDatabase.FindAssets("t:DefaultAsset", new[] { "Assets" })再过滤出文件夹，虽然会扫全项目，但只在打开窗口时扫一次，性能可以接受。

5.4 一个容易忽略的细节：.meta与版本管理

工具生成脚本之后，别忘了.meta文件也要一起提交。有时候在版本管理里看到有人只提交了.cs没提交.meta，拉下来之后 GUID 全变，场景里挂的引用全部丢失——这种事故修起来相当痛苦。

ProjectWindowUtil和AssetDatabase.ImportAsset都会自动生成.meta，正常情况下不会漏。真正的风险在于用File.WriteAllText写了文件但没触发导入，这时候.meta不存在，如果有人手快提交了，后面就埋雷了。所以我的原则是：只要写了文件，后面必须紧跟ImportAsset，一步都不能省。

6. 几套可以直接抄的模板与扩展玩法

6.1 MonoBehaviour 模板的实战取舍

模板里到底该放什么，这个问题没有标准答案，但有取舍逻辑。我的MonoBehaviourTemplate.txt只放三样东西：using UnityEngine;、命名空间、类声明加一对空括号。Awake和OnDestroy我一开始也放了，后来删了——因为大多数脚本并不需要这两个方法，留着反而是噪音，用的时候还得手动删。

这一点跟写代码时的"不要提前抽象"是一个道理。模板是给所有脚本用的，所以应该取最小公约数，只保留 100% 会用到的东西。需要额外方法的场景，单独做一个"带生命周期的 MonoBehaviour"模板就行，多一个菜单项的事。

6.2 ScriptableObject 模板里的CreateAssetMenu

ScriptableObject模板跟MonoBehaviour有个本质区别：它需要[CreateAssetMenu]特性才能在 Project 窗口右键创建实例。所以模板里的特性参数必须和类名联动：

[CreateAssetMenu(fileName = "#SCRIPTNAME#", menuName = "Config/#SCRIPTNAME#")] public class #SCRIPTNAME# : ScriptableObject { }

fileName是创建出来的资产默认名，menuName是右键菜单路径。用#SCRIPTNAME#占位符可以保证三处（文件名、资产名、菜单名）自动同步，不用手动改三遍。

menuName里的Config/前缀是分类，实际项目里可以按模块细分，比如Config/战斗/技能配置。这个层级结构在配置资产多了之后会救命，否则一长串平铺的菜单项找起来很痛苦。

6.3 从配置批量生成脚本

再往前走一步，可以做成"读一份 JSON 或 CSV，批量生成一批脚本"。这个玩法在需要快速铺量的场景里很好用，比如要根据一份技能表生成几十个技能类，每个类继承同一个基类、带上不同的常量。

核心逻辑还是File.WriteAllText加模板替换，区别在于外面套一层循环，并且循环结束后统一AssetDatabase.Refresh()一次。注意不要在循环里调Refresh，否则每写一个文件就扫一遍整个项目，几十个文件能卡好几秒。

批量生成时还有一个细节：先校验全部输入，再开始写文件。如果第 30 个文件名非法，前面 29 个已经写进去了，回滚很麻烦。我的做法是先跑一遍校验，把所有问题收集到一个列表里，全部通过才进入写文件阶段。这个思路跟数据库事务有点像，宁可整体失败，不留半成品。

6.4 一个我用了很久的小技巧

最后分享一个不太起眼但很实用的做法：给生成器加一个"最近使用"记录。用EditorPrefs存最近三次的命名空间和输出目录，打开窗口时自动填进去。因为大多数时候同一个人连续创建的脚本都在同一个模块，命名空间和目录基本不变，能少填两个框就少填两个框。

EditorPrefs是存在本机的，不会跟着项目走，正好符合这个需求。写法也简单，EditorPrefs.SetString("ScriptGen.LastNamespace", namespaceName)存，EditorPrefs.GetString("ScriptGen.LastNamespace", "Game.Runtime")读，带默认值防止首次使用时为空。

这套工具从最初的三十行菜单项，到现在两百多行的窗口版，中间改过好几轮。最大的体会是：编辑器扩展的价值不在于代码多精妙，而在于它有没有真的嵌进你的日常工作流。如果哪天你发现新建脚本的时候下意识地去点自己写的菜单项，而不是右键 Create，那这工具就算成了。