Xcode文件模板自定义：彻底修改默认注释与版权信息实操指南

直接改Xcode默认注释这事，看起来是个小需求，真要动手的人不多，但那些被公司版权声明、个人信息、日期占位符烦过几次的开发者，多半都想找机会“动一次手术”。我在好几个项目里干过这事，包括批量改模板、给团队统一规范、还有帮别人收拾改坏了的Xcode模板。今天把这套操作完完整整拆开讲，从模板结构到占位符语法，从隐藏坑到团队落地，一次说透。

1. 需求本质与改前需要想清楚的事

1.1 “改注释”背后到底是什么需求

先说清楚，标题里说的“源代码顶部的注释内容”，指的就是Xcode新建文件时自动生成的那一段灰色注释块。默认是这个样子：

code复制//
//  ViewController.swift
//  ProjectName
//
//  Created by 你的用户名 on 2024/1/15.
//  Copyright © 2024 ProjectName. All rights reserved.
//

这是Xcode从最初Mac开发时代就保留下来的一套文件头模板。几乎每个用Xcode新建过类文件的开发者都见过。问题在于，这套东西并不总能满足实际需要。有的人觉得“Created by xxx”太难看，有的人公司要求在文件头标注内部编号或者合规信息，有的人干脆不想让Xcode把当前的macOS用户名写进去，还有人所在团队有统一的标准文件头格式。

所以“修改Xcode源代码顶部的注释内容”这个需求，拆开来看，本质上是两件事：

• 修改Xcode内置文件模板（File Templates）
• 让新建的源文件头部自动带上你想要的那段注释

理解了这一点，就不会被“改注释”这个表面说法带偏，核心动作其实是改模板文件。

1.2 修改前必须想清楚的几个问题

动手之前，建议你先花两分钟确认以下几点。别急着改，很多坑都是没想清楚直接上手的。

• 你是只想改自己的Xcode，还是想给整个团队统一规范？
• 你是想要彻底替换成自己的版权模板，还是只想调整原作者信息？
• 你需要保留___FILEBASENAME___这类自动填充变量吗？
• 你的Xcode版本是多少？不同版本模板路径可能不同。
• 你能否接受修改系统目录文件带来的升级覆盖风险？

我见过一位同事，上来就改了文件模板，结果发现Apple Silicon Mac上Xcode的路径和Intel Mac略有不同，折腾半天。还有人在新版Xcode里改了模板，重启后新建文件一点变化都没有，其实是因为没有清理Xcode的缓存索引。

这些问题在动手前想清楚了，后面操作会顺利很多。

提示：改Xcode自带模板属于修改系统应用内部文件，存在被系统更新覆盖、权限变动等风险。建议操作前先备份原始模板。你可以复制一份原模板文件到桌面留底，后面想还原随时拷回去。

2. 文件模板机制拆解：Xcode的注释从哪来

2.1 模板文件的存放位置与访问方法

Xcode新建文件的模板不是写死在代码里的，而是以模板文件的形式存放在Xcode.app内部。这也是我们能动手修改的前提。

模板分两大块：

• 文件模板（File Templates）：对应Xcode的File > New > File面板里的各类文件（Swift File、Cocoa Touch Class等）
• 工程模板（Project Templates）：对应新建项目时的模板（App、Game等）

改顶部注释，重点动的是文件模板。模板文件路径在不同环境下略有区别：

code复制# 标准路径
/Applications/Xcode.app/Contents/Developer/Library/Xcode/Templates/File Templates

# 如果装了多个Xcode版本，注意认准正在使用的那一个

进入File Templates目录后，会看到按分类组织的文件夹，比如Source、Multiplatform、iOS等。文件模板本身是.rtf格式，不是Swift文件，也不是普通txt，这个很多人第一次看会不习惯。.rtf可以用Xcode内置编辑器直接改，也可以用VS Code、TextEdit（需要切换模式）等工具打开。

以iOS开发最常用的Cocoa Touch Class为例，它位于：

code复制File Templates/iOS/Cocoa Touch Class.xctemplate

在这个目录下，能看到不同类型的模板文件，包括Swift版本、Objective-C版本，以及对应的.h、.m文件模板。Swift文件对应的模板文件名类似Swift file.xctemplate，Objective-C类对应Objective-C class.xctemplate等。

2.2 模板的文件头注释是如何生成的

改模板之前，得先搞清楚模板里哪个部分控制着顶部注释。我们用Cocoa Touch Class的Swift版本举例，模板文件夹里有一个核心文件，通常名为___FILEBASENAME___.swift。这个文件的内容，就是你要新建时Xcode“复制”过去的底稿。

这个底稿顶部通常长这样：

code复制//
//  ___FILEBASENAME___
//  ___PROJECTNAME___
//
//  Created by ___FULLUSERNAME___ on ___DATE___.
//  Copyright ___YEAR___ ___ORGANIZATIONNAME___. All rights reserved.
//

注意这里面的写法：

• ___FILEBASENAME___：占位符，创建文件时自动替换为当前文件名
• ___PROJECTNAME___：占位符，替换为工程名
• ___FULLUSERNAME___：替换为系统当前用户名
• ___DATE___：替换为创建日期（格式由系统决定）
• ___YEAR___：替换为当前年份
• ___ORGANIZATIONNAME___：替换为组织名（这个在很多模板中实际显示为___ORGANIZATIONNAME___，但最终效果取决于工程设置）

也就是说，Xcode新建文件时做了一件很简单的事：把模板文件里所有___XXX___样式的占位符，逐个替换成实际值，然后把处理完的内容复制到工程目录里。我们在新建文件后看到的文件头，其实就是模板经过替换后的结果。

理解了这套机制，修改方向就清楚了：要么改模板里的固定文字，要么改占位符的替换规则，要么干脆把整段占位符都删掉换成自己的固定版权模板。

2.3 三种修改层级：个人、用户、系统范围

修改方式不止一种，不同方式的生效范围、持久程度都不一样。我实际用下来，大致分三种：

• 修改Xcode.app内部的模板文件：影响最大，改一次对系统里所有工程都生效。但升级Xcode时大概率被覆盖，而且修改系统目录需要权限，有弄坏Xcode的风险。
• 在用户目录下新建模板覆盖：在~/Library/Developer/Xcode/Templates/File Templates下放同名同结构的模板，Xcode会优先使用用户目录的模板，系统模板保持不动。升级Xcode不会影响这里。这种方式更稳，很多老手推荐。
• 在工程内设置组织名和用户名：不直接改模板，而是把FULLUSERNAME、ORGANIZATIONNAME这些变量对应的值改掉。比如用git config修改用户名，效果是新建文件的“Created by xxx”变成你想要的名字。

三种方式各有适用场景。个人强烈建议用第二种，也就是用户目录盖模板。后面实操部分我会以这种方式为主讲。好处很明显：Xcode升级不丢、系统目录不动、改错了随时删掉用户模板就恢复原样。

注意：如果你确实想直接改Xcode.app内的模板，需要用Finder定位到目录后先按住Command键拖拽或右键查看简介，把“锁定”权限改掉，然后把模板文件复制到桌面编辑完再复制回去。整个过程涉及系统文件权限，搞不好会提示“操作不能完成”。对多数人来说，用户目录盖模板是更安全的选择。

3. 核心细节解析：占位符与模板语法

3.1 占位符到底有哪些，各自代表什么

模板里的___XXX___不是乱写的。Xcode有一套固定的占位符体系，搞清楚这套体系，自定义注释才能随心所欲。我整理了个表格，方便对照。

其中几个容易忽略的细节：

• ___FILEBASENAME___不包含后缀。新建MyView.swift时，它替换为MyView，不会带.swift。
• ___DATE___的格式取决于系统的地区和语言设置。中文系统下是2024年1月15日，英文环境下是2024/1/15。想统一日期格式，可以不用这个占位符，直接在模板里写固定格式，但那样日期就不会自动更新了。
• ___COPYRIGHT___是一段组合好的版权文字，在某些模板里已经包含了Copyright © xx和All rights reserved。所以模板里常常是两行：一行单独的Copyright ___YEAR___ ___ORGANIZATIONNAME___，或者一行___COPYRIGHT___，两种效果略有区别。

实际修改模板时，最常用的操作就是把这些占位符重新排列组合，再加入自己的固定文案。

3.2 自定义模板时建议保留哪些字段

我改了这么多模板，总结出一个经验：顶部注释的信息可以精简，但下面这几样建议保留。

• 文件名（___FILEBASENAME___）
• 工程名（___PROJECTNAME___）
• 作者信息或创建时间（___FULLUSERNAME___ + ___DATE___，或者只保留其中一项）
• 版权信息（___YEAR___ + ___ORGANIZATIONNAME___，或者公司固定文案）

为什么建议保留？因为文件头注释除了给人看，还在某些自动化代码扫描、组件库打包、文档生成软件里有作用。比如一些工具会根据文件头的版权声明识别开源许可。在全公司合规审查的时候，文件头有没有统一的版权声明也是个审计点。全删掉虽然一时爽，后续不少自动化流程可能会受影响。

当然，如果你纯粹是自己写着玩，完全不在乎这些，那可以把默认注释全部删掉，只留一个文件名行。不过从经验来看，给团队做统一模板的时候，保留字段越精简越好，别让模板背上一堆“没人看但又不能删”的赘述。

3.3 如何验证占位符是否拼写正确

模板里占位符写错，最常见的结果是新建文件后留下___XXX___原样，或者整段注释显示异常。排查方法很简单：先新建一个临时的Swift文件，看一下生成的注释内容，再把模板里的占位符和表格对照一遍。

一个容易掉的坑是单下划线和双下划线的区别。模板里占位符格式是三个下划线开头、三个下划线结尾，比如___FILEBASENAME___。如果你写成了__FILEBASENAME__（两个下划线），Xcode不会替换它，文件头就留着一条“花裤子”一样的原始占位符。

我自己就遇到过类似情况。当时改一个模板，想多加一个“创建者邮箱”字段，把___FULLUSERNAME___后面加了自定义的__EMAIL__，以为随便起个名字就能被当占位符替换。结果发现Xcode根本不认识它，新建出来的文件上头明晃晃挂着__EMAIL__三个字。最后老老实实把邮箱写死在模板里，仅限自己和团队用才OK。

所以一个实用的原则：模板里的自定义变量，要么不搞，要搞就用Xcode原生支持的占位符，或者接受“写死固定值”这个事实。

4. 实操过程：三步替换Xcode默认注释

4.1 第一步：在用户目录创建模板文件夹

先说清楚，这个方案的核心思路是把修改过的模板放到用户模板目录里，让Xcode优先加载用户目录里的模板，而不是系统自带的。

打开终端，执行下面这几条命令：

bash复制# 创建用户级文件模板目录
mkdir -p ~/Library/Developer/Xcode/Templates/File\ Templates

# 进入目录确认
cd ~/Library/Developer/Xcode/Templates/File\ Templates

这个目录创建好之后，里面是什么都没有的。我们需要把系统模板复制一份过来改。但这里有个关键问题：用户目录的模板子目录结构，必须和系统目录保持一致的层级和命名，Xcode才会正确识别。

举例来说，如果你想改的是Swift File模板，那么系统里这个模板位于：

code复制/Applications/Xcode.app/Contents/Developer/Library/Xcode/Templates/File Templates/Source/Swift File.xctemplate

你需要在用户目录下创建同样的层级：

code复制~/Library/Developer/Xcode/Templates/File Templates/Source/Swift File.xctemplate

因为模板系统的加载规则是：先看用户目录，用户目录没有才加载系统目录。所以放到用户目录的模板，不会和系统冲突，只会覆盖。

假设你现在要改的是Cocoa Touch Class的Swift模板，操作指令如下：

bash复制# 先把系统模板整个复制到用户目录（保持路径结构一致）
cp -R "/Applications/Xcode.app/Contents/Developer/Library/Xcode/Templates/File Templates/iOS" ~/Library/Developer/Xcode/Templates/File\ Templates/

这条命令会把整个iOS文件模板分类复制到用户目录。好处是路径结构完全一致，不容易出幺蛾子。坏处是复制的内容有点多，但无所谓，模板文件都很小，不会占多少空间。

复制完成后，确认一下：

bash复制# 查看用户目录下的模板结构
ls -la ~/Library/Developer/Xcode/Templates/File\ Templates/iOS/

正常会看到Cocoa Touch Class.xctemplate等文件夹。

4.2 第二步：修改模板文件内容

接下来进入具体的修改环节。以Cocoa Touch Class的Swift模板为例，进入模板目录：

bash复制cd ~/Library/Developer/Xcode/Templates/File\ Templates/iOS/Cocoa\ Touch\ Class.xctemplate/

这个目录下会有多个文件，包括TemplateInfo.plist、Swift/子目录、Objective-C/子目录等。iOS开发中新建Cocoa Touch Class默认用Swift，所以Swift文件模板在Swift/子目录里：

bash复制cd Swift/
ls

正常能看到一个名为___FILEBASENAME___.swift的文件。这个就是我们要改的底稿。

用Xcode或者你习惯的编辑器打开它：

bash复制open -a Xcode "___FILEBASENAME___.swift"

打开后，能看到默认内容类似：

code复制//
//  ___FILEBASENAME___
//  ___PROJECTNAME___
//
//  Created by ___FULLUSERNAME___ on ___DATE___.
//  Copyright ___YEAR___ ___ORGANIZATIONNAME___. All rights reserved.
//

现在，把这段内容替换成你想要的格式。举个例子，如果你的公司要求每个文件头中间必须有“本项目代码仅供内部使用，未经许可不得传播”这类合规提示，可以这样改：

code复制//
//  ___FILEBASENAME___
//  ___PROJECTNAME___
//
//  Created by ___FULLUSERNAME___ on ___DATE___.
//  Copyright © ___YEAR___ ___ORGANIZATIONNAME___
//
//  Private & Confidential.
//  Unauthorized distribution is prohibited.
//

如果你个人只想清清爽爽，不想要个人信息，可以这样改：

code复制//
//  ___FILEBASENAME___
//  ___PROJECTNAME___
//
//  Created on ___DATE___.
//  Copyright © ___YEAR___ ___ORGANIZATIONNAME___ All rights reserved.
//

改完保存。

这里有几个值得强调的点：

• 模板文件是.swift拓展名，但它本质上不是一份能编译的Swift代码，只是Xcode用来生成代码的母版。所以哪怕你在里面写乱码，Xcode也不会管，切回工程里新建出来的文件才会暴露问题。
• 不要把模板文件里___XXX___这些占位符整体删光后留一堆空行。生成出来的文件顶上会有多余空行，虽然不是大问题，但看着难受。
• 注意编码，模板文件默认是UTF-8。编辑时如果用了带BOM的UTF-8，可能导致Xcode生成文件时出现意外字符。多数编辑器默认没问题，但Windows环境下编辑过的文件要小心。

4.3 第三步：清理缓存并重启Xcode

改完模板，保存关闭。这时候如果你直接打开Xcode新建文件，大概率是“没有任何变化”。因为Xcode对模板有缓存，不会每次新建都重新读磁盘上的模板文件。

正确操作是：

1. 完全退出Xcode（按Command + Q，确认Dock栏没有Xcode图标）
2. 清理Xcode的模板缓存和索引缓存

bash复制# 删除模板索引
rm -rf ~/Library/Developer/Xcode/DerivedData
rm -rf ~/Library/Caches/com.apple.dt.Xcode

DerivedData删掉会影响已编译的工程缓存，下次打开工程会重新编译索引，但这能有效确保模板被重新读取。如果不想删DerivedData，可以只删Caches下面的Xcode缓存，实测多数时候也有效。

3. 重新打开Xcode，新建一个文件

bash复制# 随便建个Swift文件验证

新建出来的文件，顶部注释应当已经变成你改的格式了。

如果新建出来的文件还是老样子，优先考虑有没有加载到用户模板。Xcode的模板加载顺序是用户目录优先，但如果你的用户目录路径写错了，或者模板文件夹命名不匹配，Xcode就会静默加载系统自带的模板，不报任何错。

一个简单的排查方式：用defaults写一个测试占位符，或者临时把用户模板目录下某个模板文件改成乱码，再新建文件看变化。不过这个方法有点粗暴，我后面单独讲更稳妥的验证方法。

4.4 一个完整的团队版权模板实例

下面给出一份我实际帮某团队配置过的模板，供参考。假设公司名是“某公司”（占位符方案里没有真实公司名），要求文件头包含：

• 文件名
• 工程名
• 创建者、创建时间
• 公司版权声明
• 保密等级

对应模板内容可以写成：

code复制//
//  ___FILEBASENAME___
//  ___PROJECTNAME___
//
//  Created by ___FULLUSERNAME___ on ___DATE___.
//  Copyright © ___YEAR___ ___ORGANIZATIONNAME___
//
//  Confidential and Proprietary.
//  All rights reserved.
//

保存到Cocoa Touch Class.xctemplate/Swift/___FILEBASENAME___.swift，重启Xcode，新建Cocoa Touch Class时就能看到效果。

注意：___ORGANIZATIONNAME___最终显示成什么，取决于工程里的Organization设置。如果你新建工程时填的Organization是“Example Inc.”，那么生成的文件头就自动带上Example Inc.。不想要这个，就把占位符换成公司固定字符串。

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

5.1 为什么改了模板，新建文件没变化

这是被问得最多的问题，处理办法也最多。

• 最常见原因：没有重启Xcode，或者Xcode没有完全退出。有些人只是关闭了项目窗口，Xcode进程还驻留在后台。务必Command + Q彻底退出。
• 第二个常见原因：模板缓存还在。删~/Library/Caches/com.apple.dt.Xcode后再试。
• 第三个原因：用户模板路径不对。Xcode只认~/Library/Developer/Xcode/Templates/File Templates这个路径，多一个空格、少一级目录都可能失效。
• 第四个原因：模板结构不对。用户目录下模板文件夹的层级必须和系统目录完全一致。比如系统里是File Templates/Source/Swift File.xctemplate，用户目录下也要这样放，不能直接放到File Templates/根目录。

5.2 修改Xcode自带模板无法保存，提示权限不足

如果你直接改/Applications/Xcode.app/Contents/...下的模板，大概率会遇到“The file couldn’t be saved because you don’t have permission”之类的问题。

两个解决办法：

• 给系统目录开写权限（不推荐，容易引发别的问题，而且操作系统更新后可能被重置）
• 改用用户目录模板（推荐，几乎所有场景都够用）

如果你只是临时改一下，可以先用Finder把模板文件复制到桌面，改完再复制回去。复制回去的时候可以用sudo命令，但需要输入管理员密码。

bash复制# 示例（谨慎使用，仅限有把握的情况）
sudo cp ~/Desktop/___FILEBASENAME___.swift "/Applications/Xcode.app/Contents/Developer/Library/Xcode/Templates/File Templates/iOS/Cocoa Touch Class.xctemplate/Swift/"

这里多说一句：直接动系统目录的模板，确实能全局生效，连新建项目都受影响。但代价是，一旦Xcode更新，这份修改就被覆盖。团队多人协作时，大家各自改系统目录，还容易发生“我改了你没有”的问题。所以统一建议走用户目录方案。

5.3 恢复默认模板的最快方式

改坏了想还原，分两种情况。

• 用户目录模板方案：直接删除用户目录里对应模板文件即可，系统自带模板立刻生效。

bash复制rm -rf ~/Library/Developer/Xcode/Templates/File\ Templates/iOS/Cocoa\ Touch\ Class.xctemplate

• 系统模板方案：如果你改的是系统目录，没有备份的情况下，最快的恢复路径是从另一台同版本Xcode的机器上拷贝模板文件，或者重装Xcode。这也是为什么我一直强调修改前先备份。

5.4 新建文件时日期格式不符合预期

默认___DATE___替换后是中文格式的2024年1月15日，有些人觉得太长，想改成2024/1/15或2024-01-15。

解决办法不是改系统模板，而是要设置macOS的日期格式偏好。在系统设置 > 通用 > 语言与地区中，把日历格式、日期格式调整为英文或自定义格式，___DATE___的输出就会改。但这样会全局影响系统其他地方的日期显示，很多人不愿意动。

另一个思路是干脆不用___DATE___占位符。在模板里写死自己想要的格式是不行的，因为日期不会自动更新。这种情况下，可以让模板生成空注释然后自己补，或者写一个简单的脚本（比如用date命令配合xcodegen或自定义模板工具）在创建文件时生成。但对绝大多数人来说，用系统默认日期格式就够了，不用纠结。

5.5 新建的Swift文件带上了奇怪的BOM或其他不可见字符

这个问题容易发生在你用了Windows记事本、或者某些在线编辑器修改过模板文件。Windows记事本保存UTF-8文件时会自动加上BOM（字节顺序标记），Xcode读取模板时会把这个不可见字符带进生成的代码里。结果就是代码文件第一行可能出现一个不知名的空字符，编译时还可能报警告。

解决方式很简单：改完模板后，用VS Code或Xcode重新保存一遍文件，确保编码为UTF-8 without BOM。如果发现已经生成的代码文件头有BOM，把那行删掉重新保存即可。

5.6 只想改某个特定项目的注释，怎么办

这个需求我也会收到。比如某个外包项目的文件头要写甲方指定的版权声明，但个人项目不想受影响。

场景一：模板方案。你可以专门为这个项目拷贝一份模板目录，在用户目录的File Templates下新建一个自定义分类，比如Custom Templates，然后把改好的模板放进去，新建文件时手动选择这个分类。

场景二：工程级方案。你可以在工程目录下放一个.xctemplate，或者用xcodegen一类的工具生成文件时控制文件头。这个方案比改Xcode模板更精细，但需要额外配置。

场景三：如果文件不是很多，也可以新建完文件后，用一段简单的脚本批量替换文件头。

5.7 团队协作时模板不一致

这个问题在很多团队里都存在。不同人的Xcode版本不同、系统用户名不同、模板状态不同，导致项目里文件头五花八门。

落地建议是这样：

• 统一用用户目录模板，避免改系统目录。
• 把模板文件放在Git仓库里，比如放到templates/File Templates/下。
• 提供一个一键安装脚本，团队成员拉取后执行，自动把模板复制到~/Library/Developer/Xcode/Templates/File Templates/。
• 在CI或代码检查阶段增加文件头合规检查，不满足要求的文件直接标红。

一键脚本很简单，大概长这样：

bash复制#!/bin/sh
mkdir -p ~/Library/Developer/Xcode/Templates/File\ Templates
cp -R templates/File\ Templates/* ~/Library/Developer/Xcode/Templates/File\ Templates/
echo "模板已安装，请重启Xcode"

这个方式比让大家各自手改模板靠谱得多，而且模板内容可评审、可回滚。我实际帮过的团队里，这套方案推广后，新提交代码的文件头从未再出过合规问题。

5.8 修改后如何快速验证是否生效

不用重新创建整个工程，随便找个项目跑一下更快。

• 打开任意一个已存在的iOS工程
• Command + N新建文件，选择Swift File
• 看生成文件头是否已经是新模板

验证时要注意：新建文件类型不同，走的模板也不同。你改了Cocoa Touch Class模板，就要用Cocoa Touch Class去验证；你改了Swift File模板，就要用Swift File验证。不要拿错模板测试，否则会误以为修改失败。

6. 我改模板时踩过的坑与经验总结

改模板这事，看着小，涉及的细节其实不少。分享几个我自己积累的实战经验。

第一件事，模板里的注释符号要保持一致。Swift用//，Objective-C里用//也通用，但有些模板里用的是/* */块注释。如果混着用，生成出来的文件看起来会比较乱。建议按语言分别维护对应模板，而不是搞一套万能模板。

第二件事，改模板时尽量保持原有的空行结构。默认模板顶部是//开头的几个注释行，然后空一行，再是实际代码。如果你在模板里把空行删了，新建出的文件会紧巴巴贴着注释，不够美观。保持“注释块 + 一个空行 + 代码”的结构，是最稳妥的习惯。

第三件事，模板文件里最好别带中文注释，尤其是团队里有人用英文系统或非UTF-8环境时，容易出现编码问题。如果公司要求中文版权声明，建议统一用UTF-8保存，并且让团队成员用同一款编辑器修改。这个建议听着基础，但真能救很多人一命。

第四件事，改模板只影响后续新建的文件，已存在的文件不会有任何变化。如果需要批量修改存量文件，得用脚本处理。我一般用sed配合perl批量替换。举个例子，把项目里所有Swift文件头里的一行文字替换成另一行：

bash复制# 示例：在项目目录下批量替换文件头
find . -name "*.swift" -exec sed -i '' 's|Copyright ___YEAR___ ___ORGANIZATIONNAME___|Copyright 2024 Example Co.|g' {} +

这种批量操作建议先小范围试跑，确认无误再全量执行。

第五件事，如果你给团队统一模板，不要只在模板层解决。更好的做法是把配置文件也纳入版本管理。比如在仓库根目录放一个README说明模板安装方式，或者提供.gitattributes来统一换行符。不然Windows和Mac的换行符不同，文件头缩进会上出乱子。

第六件事，Xcode的新建文件面板里，模板列表是分类展示的。你放在用户目录File Templates下的自定义文件夹，会直接显示为新的分类名。如果你只是想丰富自己的模板库，除了修改系统模板，也可以直接新建自定义模板文件夹，把常用模板拖进去。这种方式更适合存“个性化模板”，而不是改默认行为。

最后再说一个容易被忽略的点：占位符___FULLUSERNAME___显示的是macOS当前用户的名字，但如果你的工程是通过Git拉取到另一台电脑上，团队里每个人各自打开工程新建文件，各自的用户名会出现在文件头里。如果公司要求统一作者名，单靠改模板是解决不了的，得通过git config --global user.name或macOS账户名去统一。这一点，建议团队负责人提前理清楚。

修改Xcode模板这事，绝对算不上什么高深技术，但胜在实用。一次配置到位，后续每次新建文件都能省几秒钟手写文件头的时间。更重要的是，它能顺带解决团队里“文件头各写各的”这个老大难问题。根据我的经验，花不到半小时把这套流程跑通，接下来的收益远超这点时间成本。