企业官网建设流程全解析

如果你也是 27 届，想在课业之外自学 Unity，看到别人一周就发成果，心里难免着急。先给一个真实判断：零基础的人用一周、每天认真投入 3 到 4 小时，完全可以从“不知道 Project 面板在哪”走到“做出一个能运行、能得分、能重新开始的小 Demo”。更重要的不是这个 Demo 多花哨，而是你是否理解了 Unity 的 GameObject、Component、Script、Prefab、Collider、UI 这套最小闭环。下面按第一周真实执行顺序拆一遍，补上环境配置、单任务验证、常见报错排查和第二阶段边界。如果你是刚装好 Unity 的同学，这一篇可以当路线图用。

1. 先别管“一周能做出大作”，先把一周目标拆成验收项

1.1 27 届的零基础时间窗口，怎么安排最实际

Unity 不是一门编程语言，而是一整套游戏内容生产工具。它把“做游戏”拆成场景编辑器、组件系统、脚本语言、资源管线、构建发布好几层。一周时间只能把其中最常用的闭环走通，不可能连着色器、资源热更、性能优化、XR 设备适配都一起搞定。

如果你现在还分不清 2D 和 3D 模板的区别，也没写过 C# 脚本，那就更要把目标压低。与其在第一天收藏二十个教程，不如给自己定一周内必须完成的三件事：

• 环境能正常打开，新建项目不报错。
• 能在一个场景里创建物体，并用自己写的脚本控制它移动。
• 能完成一个包含碰撞、计分、失败或胜利条件的小游戏闭环。

我把这周拆成两段：前三天做“最小闭环”，后三天把闭环扩展成“小 Demo”。中间所有时间都围绕这一个目标，不碰多余主题。

1.2 一周结束时要交出的四份小成果

很多新手会用“我看了多少集教程”来衡量进度，这其实是陷阱。看教程不算产出，跑通才算。第一周结束，你应该能拿出四样东西：

第一，一个能双击打开的项目目录。项目里至少有一个正常保存的 Scene，目录结构里能看到 Assets、Scripts、Scenes 这些基础文件夹。

第二，一份自己敲出来的控制脚本。不用长，但必须是理解后重写的，不是从教程里整段复制的。能解释每一行在干什么，能解释为什么用Update、为什么乘Time.deltaTime。

第三，一个可玩的 Demo。建议做成“玩家收集物品”或“躲避障碍物”，包含角色移动、碰撞检测、UI 计分和重新开始。

第四，一次完整构建。在 Build Settings 里把当前场景加进去，然后导出一个 Windows 或 macOS 可执行文件。这一步很关键，很多人在编辑器里跑得好好的，构建就是失败，问题往往出在场景没加进 Build、脚本报错或模块缺失。第一周就尝试构建，能提前暴露很多隐藏问题。

这里提醒一句：如果每天只能投入不到一小时，一周七天也就七小时，可能只能完成前两项。这不是失败，是现实。没必要因为网上有人“一周做出了完整 Demo”就焦虑，起点和每天可用时间不同，进度本来就不一样。

2. 环境配置不是随便装一下：从安装到 License 一次干净

2.1 Unity Hub、编辑器版本、Build 模块之间的关系

第一次接触 Unity，最容易踩的第一个坑是直接去官网下载 Editor 安装包，却不知道 Unity Hub 才是统一入口。Unity Hub 可以理解为版本管理器，Editor 才是真正干活的程序。建议先装 Unity Hub，再通过 Hub 安装指定版本的 Editor。

版本选择上不用追新。Unity 更新速度很快，新版本可能带来新渲染管线，也会带来新的兼容问题。对初学者来说，选择当前支持周期内的 LTS 长期支持版本更稳。进入 Hub 的“安装”页面，会看到几个带 LTS 标识的版本，选其中一个即可。

安装时还会让你勾选模块。第一周先按桌面平台走，不要一次性把 Android、iOS、WebGL 全勾上。每个模块都占磁盘，也会让安装过程变得很慢。等后面确定要在手机上或网页里跑 Demo，再打开 Hub 补装对应模块，这不影响已有项目。

磁盘空间要提前留够。Unity Editor 本体加缓存通常在 10GB 以上，再算上后续项目资源和构建产物，第一周至少留出 20GB 比较稳妥。机器配置偏低也能跑，但打开大工程、做烘焙或构建时会明显变慢，初学者建议从小场景开始，别一开始就加载高精度模型。

2.2 License 激活报错：为什么网上到处是这条红字

安装完成后第一次打开 Unity Editor，很多人会看到一条非常经典的红字：

No valid Unity Editor license found. Please activate your license.

翻译一下就是：Editor 没找到有效许可，需要激活。这通常不代表安装坏了，而是 Unity Hub 还没有登录账号，或者个人许可证没有完成绑定。

处理顺序很固定：先在 Unity Hub 右上角登录 Unity 账号，再打开菜单里的 Manage Licenses，添加一个 Personal 许可证。Unity 官方为个人用户提供免费许可证，只要年收入或公司规模低于规定门槛，就可以正常使用个人版。对在校学生来说，个人版足够完成学习和项目实践。

如果登录后仍然提示没有许可证，先做两件小事：一是重启 Unity Hub，二是检查网络是否把登录请求拦截了。学校机房或公司内网有时会限制外部登录，可以临时换手机热点试一次。激活成功后许可证会出现在 Manage Licenses 列表里，再打开 Editor 即可。

这里也多说一句：不要看到“激活失败”就在网上搜索奇怪渠道。个人版本来就不收费，正常激活只用一两分钟。为了省这一步去用来路不明的修改版或补丁，既不稳定，也可能埋下安全问题，完全不值得。

2.3 模板选 2D 还是 3D，就看你控制的角色怎么移动

Unity Hub 里新建项目时会让你选模板。新手容易纠结，其实可以按“最终想在哪个平面上移动”来判断。

如果要做类似“平台跳跃、横版闯关、顶视角收集物品”这种在平面里玩的游戏，选 2D 模板。2D 模板默认使用 Sprite Renderer 和正交摄像机，场景里的坐标轴用 X 和 Y 控制移动，理解起来直接。角色移动、碰撞检测都有对应的事件方法，代码量也更少。

如果要做类似“第三人称漫游、第一人称探索”这种有纵深空间感的游戏，选 3D 模板。3D 模板使用透视摄像机，场景里物体有体积，刚体碰撞和空间移动更接近真实世界。玩家控制时通常需要处理 X、Z 两个水平轴和 Y 轴。

更准确的判断标准是“摄像机视角”和“碰撞体类型”。2D 游戏即使角色贴图是用 3D 素材渲染出来的，只要玩法发生在平面坐标系里，依然用 2D 物理更合适；反之，玩法本身需要跳上立体平台、绕到障碍物后方，就要用 3D 场景。第一周不建议在模板选择上花太多时间，先认准一个模板把 Demo 做出来。后面掌握基础后，模板之间可以切换，不是一锤定音。

还要注意一点：新版 Unity 的新手模板通常基于 URP 或默认渲染管线。如果学习中遇到 Shader 相关报错，先别紧张，多数情况下是你打开的项目模板与教程环境不一致。解决办法不是马上去学 Shader，而是把教程使用的 Unity 版本和渲染管线看清楚，尽量保持一致。

3. 前三天建立最小闭环：一个能听懂指令的方块

3.1 先理解 Scene、GameObject、Component 三个概念

第一天的核心任务，不是写很多代码，而是建立 Unity 的对象模型。

Unity 场景里所有东西都叫 GameObject，中文叫游戏对象。可以是方块、球体、模型、灯光、摄像机，甚至一个空物体。GameObject 本身只是“一个存在”，它有什么能力，取决于身上挂着的组件。

Transform 是每个 GameObject 都有的组件，负责位置、旋转、缩放。MeshRenderer 让物体显示出来。Collider 让物体有碰撞范围。Rigidbody 让物体受物理影响。脚本也是一种组件，你可以把脚本挂到 GameObject 上，控制它的行为。

很多新手理解不了“为什么 Unity 程序不是从 Main 函数开始执行的”，原因就在这里：Unity 的入口是场景里的一个个 GameObject，脚本组件会在场景加载时被 Unity 引擎调用相应方法。你不用控制主循环，只需要在Start和Update这些规定好的方法里写逻辑。

所以前三天的一个小目标是：能解释“把脚本拖到 Cube 上”到底发生了什么。拖上去之后，Cube 的组件列表里多了一项，那个脚本组件从这一刻起就跟着 Cube 的生命周期走了。理解这个模型，比记住任何快捷键都重要。

3.2 第一个脚本写什么：移动、打印、修改公共变量

打开 Unity 后，建议在 Assets 下建一个 Scripts 文件夹。右键创建 C# Script，文件名改成 MoveCube，然后双击打开编辑。Unity 要求脚本类名和文件名保持一致，否则挂载时会报错。

第一份脚本不用追求复杂，先让一个 Cube 动起来：

using UnityEngine; public class MoveCube : MonoBehaviour { public float speed = 5f; void Update() { float horizontal = Input.GetAxis("Horizontal"); float vertical = Input.GetAxis("Vertical"); Vector3 direction = new Vector3(horizontal, 0, vertical); transform.Translate(direction * speed * Time.deltaTime); } }

这段脚本的意思很简单：每帧读取键盘方向键，得到一个方向向量，乘以速度，再乘以一帧的时间，让物体移动。

脚本里的public float speed会在 Inspector 面板显示出来，你可以直接在编辑器里改数值。这一点是 Unity 和新手理解的传统编程最大的不同：变量不一定要写在代码里写死，它可以暴露给编辑器，让策划或你自己随时调整。

写完脚本后，在 Hierarchy 里创建一个 Cube，把脚本拖到 Cube 上，点击播放，按方向键或 WASD，Cube 应该会移动。如果不动，先检查脚本有没有编译报错、是否真的挂在 Cube 上、Inspector 里是否能看到脚本组件。

3.3 用 Debug.Log 验证“代码真的在跑”，再进入下一环节

新手最容易碰到的诡异情况是：代码看起来没问题，但物体就是不动。这时候先别急着改参数，先确认代码是否真的执行了。

在脚本里加一行Debug.Log：

void Update() { Debug.Log("Update is running"); // ... }

点击 Play 后，看 Console 面板有没有输出。如果有输出，说明脚本和 Update 生命周期正常，问题出在输入、速度或方向；如果没有输出，说明脚本可能没挂上、类名不匹配，或者有编译错误阻止了整个脚本集运行。

这个习惯看起来很基础，却是第一周最值得建立的排查意识。遇到问题先分层次：代码跑没跑？如果跑了，是输入没读到还是移动逻辑不对；如果没跑，先看编译错误和挂载状态。不要一上来就怀疑 Unity 坏了，大多数情况下是脚本没有生效或参数没有赋值。

我还建议新手第一天就学会看 Console 面板的日志级别。普通日志是白色或灰色，警告是黄色，错误是红色。编译错误一旦出现，游戏会停止进入 Play 状态，先把红字修掉再继续。日志不一定都是中文，报错行号会指向具体脚本文件，点一下就能定位到问题代码，这比反复重启编辑器高效得多。

4. 后三天把 Demo 串起来：摄像机、碰撞、预制体、UI

4.1 摄像机跟随的经典做法和 LateUpdate 的原因

当角色开始移动，第二个问题就出现了：角色跑出画面。解决办法是让摄像机跟随目标。

很多新手会把代码直接写到Update里，这样通常也能动，但更稳的做法是写在LateUpdate里。原因是 Unity 每帧执行顺序通常是：先执行所有Update，再执行LateUpdate。角色在Update里移动完，摄像机再用角色的最新位置去跟随，画面才不会出现“摄像机有半帧延迟”的抖感。

一个最简版本如下：

using UnityEngine; public class CameraFollow : MonoBehaviour { public Transform target; public Vector3 offset = new Vector3(0, 0, -10); void LateUpdate() { if (target == null) return; transform.position = target.position + offset; } }

如果角色在 2D 平面上移动，摄像机通常要保持一段 Z 轴距离，否则正交摄像机的裁剪面可能剪掉角色。offset 的 Z 设为 -10，就是把摄像机放在世界前方看过去，这是 2D 场景很常见的做法。

挂载时不要忘记把 Player 拖到target字段上。如果你发现摄像机没跟随，第一件事不是改代码，而是看 Inspector 里 target 是否为空。这个字段一旦为空，if (target == null) return;会直接导致方法什么都不做，摄像机自然停在原地。

4.2 碰撞和触发：不要以为挂上 Collider 就一定能生效

角色能移动后，开始做“碰到物品就算收集”的逻辑。这里要先区分碰撞和触发。

碰撞是物理层面的事。两个物体要发生碰撞，至少其中一个要有 Rigidbody，另一个要有 Collider。如果只是挂 Collider 而不加 Rigidbody，物体之间可能直接穿过，因为你没有告诉 Unity“这是一个受物理影响的对象”。

如果是“角色走过去碰到物品”，更常用的是触发。触发器可以理解为“能感知范围但不产生物理阻挡”的碰撞体。设置方法是：给物品加上 Collider，并勾选 IsTrigger，然后在角色的脚本里写触发事件。

以 2D Demo 为例，代码是这样：

private void OnTriggerEnter2D(Collider2D other) { if (other.CompareTag("Player")) { Destroy(gameObject); } }

这段代码挂在物品身上：当有东西进入触发范围时，判断进入者是不是 Player，如果是，就销毁当前物品。

新手最容易在这类代码上翻车，原因主要有三种。第一，方法名写错。2D 场景要用带2D后缀的方法名，比如OnTriggerEnter2D，写了 3D 版本的OnTriggerEnter不会自动提醒你，只是不会被执行。第二，忘记给物品勾选 IsTrigger，导致事件一直不被触发。第三，Tag 没有设置。如果 Player 对象没有 Tag，CompareTag("Player")会返回 false，碰撞发生后什么都不会发生。

这里有个排查口诀：先看 Console，再看组件，再看命名，最后看 Tag。顺序不要乱。

4.3 预制体和生成代码：让收集物不再靠手摆

当你手动摆了十个收集物之后，会意识到一个问题：如果收集物要被销毁，重复创建怎么办？如果场景里有几十个相同物品，难道每个都要逐个调整属性吗？

Unity 给出的答案是预制体 Prefab。把做好的一个收集物从 Hierarchy 拖到 Assets 文件夹里，它就变成了一个可复用的预制体。之后想改颜色、改碰撞体、改标签，只需要修改预制体本身，场景里所有实例都会同步变化，不用再逐个物体去调。

用到代码自动生成时，可以把预制体引用暴露成变量：

public GameObject collectiblePrefab; void SpawnCollectible(Vector3 position) { Instantiate(collectiblePrefab, position, Quaternion.identity); }

Instantiate是 Unity 里很核心的方法，作用是根据预制体创建新实例。Quaternion.identity 表示不旋转。

第一周不建议去实现复杂的对象池。对象池是为了避免大量创建和销毁物体带来的卡顿，属于性能优化话题。你只要理解 Instantiate 和 Destroy 是创建和销毁的两个基本操作即可。如果你发现 Demo 卡顿，先看是不是每帧都在生成大量物体，而不是马上引入对象池增加复杂度。

4.4 UI 计分与游戏结束：先让 Demo 成为完整循环

一个没有 UI 的 Demo 很难让人感受到“游戏做完了”。所以后三天要加入 Canvas、文本和简单的开始结束逻辑。

在 Hierarchy 右键选择 UI，能看到 Canvas。第一次创建 UI 时，Unity 可能会提示导入 TMP Essentials。TextMeshPro 是新版 Unity 推荐的文本组件，字体渲染效果比旧版 Text 好，按提示导入即可。所有 UI 都要放在 Canvas 下，否则无法显示。

计分逻辑不需要复杂。在脚本里声明一个分数变量，收集到物品时加一：

using UnityEngine; using TMPro; public class GameManager : MonoBehaviour { public TMP_Text scoreText; private int score; public int winScore = 5; public void AddScore(int value) { score += value; scoreText.text = "Score: " + score; if (score >= winScore) { Debug.Log("You Win!"); Time.timeScale = 0f; } } }

把物品销毁前的代码改成先调用GameManager.AddScore(1)，再销毁自己。这样每收集一个物品，分数就会变化。

这里有两个容易踩的坑。一是 TMP_Text 类型引用没有赋值，需要在 Inspector 里把 Canvas 下的 Score 文本拖到脚本的 scoreText 字段上；二是Time.timeScale = 0会让游戏暂停，但暂停后如果还想点击重新开始按钮，按钮逻辑通常会失效，因为时间尺度被锁住了。

如果想做重开功能，更稳妥的做法是加载场景：

using UnityEngine.SceneManagement; public void RestartGame() { Time.timeScale = 1f; SceneManager.LoadScene("Game"); }

注意：场景名必须和 Build Settings 里加入的场景一致。很多新手在编辑器里点击重开按钮没有反应，就是因为当前场景没有加进 Build Settings，或者场景名写错了。

到这一步，你的 Demo 已经具备“玩家移动、收集物品、分数变化、胜利条件、重新开始”的完整闭环。这个闭环就是第一周成果最实用的验收标准。

5. 第一周高频问题排查：把顺序练成肌肉记忆

5.1 排查顺序：现象、输入、环境、参数、工具

第一周大概率会遇到报错，遇到报错不可怕，可怕的是乱试。新手容易犯一个错误：看到“物体不动”就改 speed，看到“Unexpected symbol”就重装编辑器。正确做法是固定一套排查顺序。

先看现象。是物体完全不动，还是动得不对，还是只有点击 Play 时报错？现象描述得越具体越好。

再看输入。你编辑器的输入有没有通过？方向键在游戏窗口里是否被选中？有些时候你一直在看 Scene 窗口，但游戏输入是发生在 Game 窗口的。

再看环境。脚本有没有编译错误？License 是否掉了？依赖插件是否缺失？平台模块是否没装？这类问题通常不是代码逻辑造成的，而是运行环境不完整。

再看参数。引用字段有没有在 Inspector 里赋值？速度是否为 0？Tag 是否设置？IsTrigger 是否勾选？

最后才是工具本身。确认 Unity 版本、渲染管线、第三方插件兼容性。只有前四层都检查过，才轮到怀疑工具坏了。

5.2 编译错误、License 提示、DLL 加载失败分别怎么看

第一周最常见的三类报错，需要能分得清。

第一类是编译错误。Console 里会出现带 CS 前缀的错误，例如 CS0246。这种错误通常有具体文件路径和行号。点开后，问题一般集中在：类名和文件名不一致、缺少 using 命名空间、变量名拼错、括号没配对。编译错误会导致整个脚本集无法重新编译，游戏不能进入 Play 模式。修复顺序是先看第一条错误，不要从中间开始猜。

第二类是 License 提示。表现是开头出现的 “No valid Unity Editor license found”。这属于环境问题，解决办法是回到 Unity Hub 登录账号并激活个人许可证，重启 Editor。

第三类是动态链接库加载失败。报错里常见这样一句：

DllNotFoundException: Unable to load DLL 'slua'

出现这类问题，说明项目里某段代码依赖了一个 DLL 动态库，但 Unity 运行时没有找到它。这种情况多出现在下载的旧项目、第三方插件或热更框架项目中。常见原因有三个：插件没有导入完整、插件支持的硬件架构与当前平台不匹配、项目没有把插件放在正确目录下。

遇到 DllNotFoundException，不要急着去网上重新下载 DLL 乱放。先看这个 DLL 属于哪个插件，回到插件官方文档确认导入方式，再确认项目是否完整恢复。如果只是学习阶段用不到该功能，可以直接删除相关脚本和引用，避免被无关错误卡住。

5.3 那些“你根本不该第一周背锅”的报错

有一些报错看起来吓人，但和学习内容无关。

比如 XR 设备开发中常见的RenderPassIndex越界报错，通常是项目用了 Pico 或 Quest SDK，脚本与渲染管线不匹配导致的。你没有连接 VR 设备，没必要在第一周研究它。

再比如 WebGL 构建后帧率不稳定，这是一个包含资源加载、内存占用、渲染优化、引擎设置的综合问题。第一周如果只是在本地桌面环境跑，不必过早引入 WebGL 打包包袱。

还有 C# 的委托和事件相关的问题，比如Action与UnityAction的区别。第一周你会大量使用 Unity 生命周期方法和按钮绑定，但还不一定能理解事件机制。把它放到第二周或第三周去学，比现在硬啃更有效。

处理这类报错的原则是：先判断“这个报错是否真的影响我当前场景运行”。如果不影响，记录到笔记里，等做到相关平台再回来解决；如果影响，就顺着 Console 的第一个红字往上游查。不要因为被吓到，就去学习一堆和任务无关的进阶概念。

6. 网上很火不等于本周要学：给进阶内容划三条边界

6.1 Addressables、Shader、热更、IL2CPP 这一类为什么先缓一缓

打开任意 Unity 相关搜索页面，都能看到大量进阶术语：Addressables、Sprite Atlas、Shader、IL2CPP、WebGL 优化、微信小游戏打包、热更框架、MCP 插件。它们存在感很强，但和第一周任务没有直接关系。

我列一个简单的“本周不碰”清单：

这不是说这些主题不重要。任何一个做到后期都可能用到。但第一周的大脑带宽很有限，如果同时学习 Addressables、Shader 和对象池，你会发现自己既没学好 C#，也没理解 GameObject，最后所有项目都开到一半就放弃了。

正确的做法是给每个主题打上时间标签。第一周只学“怎么做出能玩的闭环”，第二周开始给 Demo 加菜单和音效，第三周再思考如何优化资源结构。进阶主题等到它真正阻塞你的下一步目标时，自然就明白为什么要学、该学到什么深度。

6.2 版本洁癖和时间黑洞：学习期间最容易忽略的底线

很多新手在评论区或讨论区看到别人用什么版本，就反复卸载重装。结果第一周有两天花在下载和破解环境问题上，这非常不划算。

Unity 个人版是可以免费正常激活的，没有理由使用任何非官方渠道。如果你用的是学校机房电脑，也不要因为在旧版本上打不开新项目就反复重装，先查看项目是用哪个 LTS 版本创建的，再安装对应版本。

时间黑洞还有几个典型场景：为了找“最好用的代码编辑器”折腾半天、为了一个插件反复导入导致报错、看到一个很炫的 Shader 教程就开始改渲染管线。第一周最稀缺的资源不是功能数量，而是稳定时间。我的建议是：装一个 LTS 编辑器，写代码用默认的 IDE，画面跑通之前不装任何非必要插件。

7. 一周结束怎么复盘，以及下一步往哪走

7.1 六个自查问题

一周结束时，不要只看“我做了几个 Demo”，而要回答下面六个问题：

第一，能不能不看任何资料，从一个新的空场景开始，创建 Cube、挂脚本、控制移动？如果能，说明你已经摆脱了对教程项目文件的依赖。

第二，能不能解释为什么有的代码写在Start，有的写在Update，有的写在LateUpdate？能解释，说明你理解了 Unity 的生命周期。

第三，能不能说出 Collider 和 Rigidbody 各自负责什么？能说出，说明你理解了物理系统的分工。

第四，当一个物品需要被销毁计分时，你能否独立写出含 Tag 判断的触发代码？如果可以，碰撞系统就算过关了。

第五，你能不能修改一个“物体不动”的问题，并且按“看 Console、查组件、查引用、查参数”的顺序排查？会这个，比会十个快捷键都值钱。

第六，你能否导出一个桌面可执行文件并运行它？能导出，意味着 Demo 真正脱离了编辑器环境。

如果六个问题都能答上来，这一周就是合格的。答不上来也没关系，每周复盘的目的不是打击自己，是找到下一周该补的缺口。

7.2 下一周方向：把同一个 Demo 重做，不换新项目

第二周最不建议做的事情，是立刻换一个新项目去学新功能。更有效的方法是把你第一周做的 Demo 当作素材，做一次重做升级。

重做的意思不是从头开始打字，而是在理解结构的基础上做三件事。第一，把代码拆成更清晰的角色：Player 只管移动，Collectible 只管被收集，GameManager 只管分数和状态。第二，给 Demo 增加开始界面和结束界面，让玩家进入游戏后先看到“如何操作”，胜利后看到“得分统计”。第三，手动玩十遍，记录哪里手感不好，尝试调整速度、生成频率和惩罚规则。

把一个 Demo 从粗糙做到完整，比做三个半成品更能建立信心。你会在过程中发现很多“第一周没注意的细节”：摄像机边界、玩家出生点、UI 与场景的适配、按钮点击音效、重新开始后得分没有清零。这些问题每个都对应系列知识点，是天然的进阶路径。

7.3 27 届后续节奏建议

如果你是 27 届学生，接下来还有课程、实验和其他课业，不建议把所有空闲时间都押在一周内。更合理的是把 Unity 学习放进一个季度规划里：前两周跑通一个 Demo，第二个月做这个 Demo 的完整版本，第三个月尝试第二个不同类型的小项目。

每次项目结束，把场景截图、可执行文件和一段