Unity射击小游戏源码拆解、版本迁移与射击手感调优

简介：面向Unity3D初学者与游戏开发课程实训的初级射击小游戏项目，基于Unity5.0构建，适合用来打通C#脚本、场景组织与基础交互等入门环节。压缩包共28个文件，约33.73MB，以dll依赖库、config配置、assets与resource资源包、场景数据及exe可执行文件为主，并包含默认资源与日志文本，能较完整地保留可运行工程结构，便于直接启动体验和对照拆解。项目围绕射击玩法串联多个知识点：用C#变量与条件判断实现射击数、消灭数统计；借助粒子系统与音频管理完成枪口火花、弹道表现和射击音效；通过Input类监听WASD移动、QE视角切换及ZC、HN等特殊动作；同时涉及Scene Management场景切换、Transform控制、光照与材质调整。目录结构清晰，适合按模块阅读脚本、观察预制资源与场景配置。已有1585人学习下载，可作为课程作业、入门练手与功能扩展的参考样本。

1. 一个 zip 里的射击小游戏：它能省你哪几天工

拆包之前先说结论：unity射击游戏.zip这类 Unity 射击小游戏源码，价值不在「能直接上线」，而在它把一套完整的射击循环——移动、瞄准、开火、命中、掉血、刷怪、结算——用最少的脚本串起来了。对刚接触 unity3D 的人，从零搭这套循环，光是调射线检测和对象池就够折腾两三天；对 unity5.0 时代留下来的老工程，它能当一份「可运行的行为参照」。但它也带着明显的时代痕迹：组件快捷属性、旧版场景加载 API、可能存在的 UnityScript 脚本，直接拖进新版编辑器大概率是粉色场景加一屏红字。所以这份资源适合两类人：想快速看懂射击玩法骨架的新手，以及手上有一堆老工程要迁移、需要一个样本来试刀的人。下面按「拆骨架、过版本、调手感、避坑、验收」的顺序把它拆开。

2. 先拆骨架：Assets 目录、场景与脚本的依赖关系

2.1 解压后先别开 Unity，先看这四样东西

很多人拿到包的第一动作是双击工程文件、等进度条。更稳的顺序是先看目录，因为这一步就能判断这个包是「干净工程」还是「作者整个项目目录打了个压缩包」。打开根目录，重点确认四类内容：Assets/、ProjectSettings/、Packages/（老工程可能没有）、以及有没有混进来的Library/、Temp/、obj/。Library是本地缓存，体积大且跟机器绑定，带进来只会让首次导入变慢甚至冲突，直接删掉让编辑器重建。

第二件要看的是.meta文件是否齐全。Unity 靠.meta里的 GUID 维系场景、预制体、材质之间的引用，Assets下每一个文件都应该有同名.meta。如果压缩包在打包时用了「只保留源码、过滤隐藏文件」的选项，.meta会全部丢失，编辑器重新生成时 GUID 全变，结果是场景里一堆Missing (Mono Script)、预制体上的材质全空。这是老资源包最常见的一种「看起来能打开、其实全断了」的形态。

第三件是脚本语言构成。翻一遍Assets下的.cs和.js数量，如果存在大量.js，说明它是 UnityScript 时代的产物，较新的编辑器已经不支持，必须逐个人工翻成 C#，工作量要提前估进去。第四件是场景文件，Assets下搜.unity，通常会有Main、Menu、Game之类几个，先记下名字，后面看 Build Settings 里挂了哪几个。

提示：解压后第一件事是复制一份原始包存档，所有改动在副本上做。老工程的迁移过程不可逆，改坏了回不去。

2.2 用依赖关系表倒推「哪个脚本在控制什么」

射击小游戏的脚本数量通常不多，十到二十个，但命名往往很随意，GameManager、Manager、GameController可能同时存在。与其逐个点开读，不如先按「一个射击循环需要哪几块」去归类，再对着文件找。一个最小可运行的射击 Demo 至少包含这几块：玩家控制器、武器/开火逻辑、子弹或射线判定、可受击目标、敌人生成、分数与 UI、游戏状态机。

建这张表的过程本身就是理解工程的过程。做完之后你会发现两个信号：一是某个职责完全没有对应脚本，说明这个包是残缺的或依赖了外部 Standard Assets；二是某个职责被拆成了五六个脚本互相引用，说明作者后期在打补丁，这种工程迁移时要格外小心循环依赖。

接着看场景。在编辑器里打开主场景，Hierarchy 从上往下扫一遍，把每个一级节点和它挂的脚本对应起来。重点确认三件事：主摄像机是不是被正确指派给了武器脚本的相机字段；玩家对象上有没有CharacterController或Rigidbody；UI 是用 uGUI 的 Canvas 还是更老的GUIText。如果是GUIText，基本可以判定这个包的年代在 Unity 4.6 之前或紧邻那个时期，UI 部分要整体重做。

2.3 第一次 Play 之前的最小改动清单

不要一上来就点 Play。老工程在编辑器里运行失败的信息往往藏在几十条警告中间，先做一轮静态检查，能省掉大量猜测。按下面这个顺序过：

1. 打开ProjectSettings/InputManager.asset，确认Horizontal、Vertical、Mouse X、Mouse Y、Fire1这几个轴存在。老工程如果只拷了Assets没拷ProjectSettings，输入轴会缺失，运行时报Input Axis Fire1 is not set up。
2. 打开ProjectSettings/TagManager.asset，把脚本里用到的字符串 Tag 和 Layer 逐个核对。射线检测依赖 LayerMask，层名不一致时射线会静默打空，不报错，最难查。
3. 打开 Build Settings 的场景列表，确认至少有一个场景，且顺序正确。空列表在编辑器里能跑，打包出来就是黑屏。
4. 检查所有预制体引用。在 Project 窗口逐个点开Prefabs目录下的资源，看 Inspector 里有没有字段显示None。有的话先别急着修，记下来，等版本迁移做完再统一处理，否则修两遍。

这四步做完再点 Play。此时如果还有报错，报错信息会干净很多，指向性也强。我见过太多人在一屏红字里翻找，最后发现真正的问题只是 InputManager 里少了一个轴。

3. 让 Unity 5.0 的老工程跑起来：API 替换与工程设置对齐

3.1 版本断层的三层：脚本层、资源层、工程配置层

unity5.0 到较新的 LTS 之间，断层不是一层，而是三层，而且三层的表现完全不同。脚本层的断层是编译错误，最吵但最好修；资源层的断层是粉色材质和丢失引用，不报编译错但画面全废；工程配置层的断层最阴，编辑器里一切正常，打包或换机器才出问题。

脚本层的主要变化集中在几个方向：组件快捷属性（rigidbody、renderer、audio、camera）在 5.x 时代已标记过时，后续版本逐步移除，必须改成GetComponent<T>()；场景加载从Application.LoadLevel迁移到SceneManager.LoadScene；旧版粒子系统的ParticleEmitter、ParticleAnimator被 Shuriken 取代；GUIText、GUITexture让位于 uGUI。如果包里还有.js，那连语言层都要换。

资源层的核心是着色器。Unity 5.0 引入 Standard 着色器，工程里如果残留着更早的Diffuse、Specular或者第三方自定义 shader，在新版本里可能整个失效，材质球变粉。粉色不是「材质丢了」，而是「shader 编译失败或找不到」，两者处理方式不同：前者重新指认材质，后者要换 shader。

工程配置层包括 Input Manager、Tag/Layer、Physics 碰撞矩阵、Quality 设置、Graphics 的 Always Included Shaders。这些东西不在Assets里，压缩包经常漏掉，而它们恰恰决定了「编辑器能跑、打包就崩」的那类问题。

3.2 用批量替换脚本过一遍 C# 脚本

脚本数量超过十个之后，手工改容易漏。我一般写个一次性脚本先做机械替换，再人工复核。前提是先把整个工程纳入版本控制，或者至少复制一份备份，因为正则替换是有破坏性的。

import re from pathlib import Path # 规则按「先具体、后宽泛」排序，避免后面的规则覆盖前面的结果 RULES = [ # 场景加载：把旧 API 连同命名空间一起换掉 (r'Application\.LoadLevel\s*\(', 'SceneManager.LoadScene('), (r'Application\.loadedLevel\b', 'SceneManager.GetActiveScene().buildIndex'), # 组件快捷属性 -> GetComponent；只替换独立单词，避免误伤变量名 (r'(?<![\w.])rigidbody\b', 'GetComponent<Rigidbody>()'), (r'(?<![\w.])renderer\b', 'GetComponent<Renderer>()'), (r'(?<![\w.])audio\b', 'GetComponent<AudioSource>()'), (r'(?<![\w.])camera\b', 'GetComponent<Camera>()'), ] root = Path('./Assets') for cs in root.rglob('*.cs'): text = cs.read_text(encoding='utf-8', errors='ignore') original = text for pattern, repl in RULES: text = re.sub(pattern, repl, text) # 用到 SceneManager 就必须补命名空间，否则编译不过 if 'SceneManager.' in text and 'using UnityEngine.SceneManagement;' not in text: text = text.replace('using UnityEngine;', 'using UnityEngine;\nusing UnityEngine.SceneManagement;', 1) if text != original: cs.write_text(text, encoding='utf-8') print(f'patched: {cs}')

这段逻辑的核心是「窄规则优先 + 负向环视」。(?<![\w.])的作用是确保rigidbody前面不是字母、数字、下划线或点号，这样myRigidbody、other.rigidbody不会被误替换。即便如此，仍有两类误伤必须人工过一遍：注释里的rigidbody会被替换成一大串GetComponent，读起来很别扭；局部变量Renderer renderer = ...里的声明和后面的使用会变成两套写法。

替换完成后的复核重点不是看改了多少，而是看「哪些没改」。搜一遍GetComponent<Rigidbody>()出现的次数，如果某个脚本里每一帧都在调它，那就是性能隐患，得提取成成员变量在Awake里缓存。老代码里rigidbody.velocity = ...写在Update里是常态，机械替换后变成每帧一次GetComponent，虽然现代 Unity 对GetComponent有优化，但这个习惯该改。

还有一处容易漏：SceneManager.LoadScene的参数是场景名或 buildIndex，老代码里Application.LoadLevel(1)传的是索引，替换后语义一致，但如果原代码用的是Application.LoadLevel("Game")而新工程里场景改名了，运行时会抛「场景不在 Build Settings 中」。所以替换完要回头对一遍 Build Settings 的场景列表。

3.3 资源层：材质、着色器与预制体的连锁失效

脚本编译通过只是第一关。打开场景后常见画面是：天空盒正常、UI 正常，但所有模型是品红色。逐层排查的顺序是材质 → 着色器 → 预制体引用。

先在 Project 窗口搜t:Material，全选，看 Inspector 里 Shader 那一栏。如果是Standard但仍显示粉色，说明是渲染管线或平台相关的编译问题；如果显示Hidden/InternalErrorShader或空白，说明原 shader 已不存在。处理方式是把 Shader 改成Standard，然后逐个把_MainTex、_Color重新指认。老工程里贴图命名通常很规律（xxx_Diffuse、xxx_Albedo），批量指认比一个个点开快。

预制体的问题更隐蔽。场景里看着正常，一实例化新敌人就是白模，原因是预制体上的MeshRenderer引用的材质在打包时被过滤掉了，或者预制体本身的引用链断在某一层。判断方法是双击预制体进入 Prefab 模式，看 Inspector 里有没有Missing。有的话没法自动修，只能重新拖引用。

还有一类是Always Included Shaders。如果工程用了自定义 shader，而新工程的ProjectSettings/GraphicsSettings.asset里没把它加进去，编辑器里正常，打包后运行时该材质变粉。这个坑的典型特征是「编辑器能跑、打包出来花屏」，排查时容易被误导到平台差异上。

3.4 工程配置层：Input Manager、Tag/Layer、Build Settings

这一层没有代码可改，全是资产文件的对齐。最省事的做法是：如果原始压缩包里带了ProjectSettings，直接用它的InputManager.asset和TagManager.asset覆盖新工程的对应文件，再手动补齐新版本多出来的字段。如果没有，就按脚本里出现的字符串逐个补。

用一条命令把所有脚本里用到的 Tag 和 Layer 字符串捞出来，比在编辑器里翻快：

# 捞出所有 CompareTag 和 LayerMask 相关的字面量，去重后人工核对 grep -rhoE 'CompareTag\("([^"]+)"\)' Assets --include=*.cs | sort -u grep -rhoE 'LayerMask\.(NameToLayer|GetMask)\("([^"]+)"\)' Assets --include=*.cs | sort -u grep -rhoE 'gameObject\.tag\s*==\s*"([^"]+)"' Assets --include=*.cs | sort -u

这几条命令输出的结果就是必须存在的 Tag 和 Layer 清单。缺哪个补哪个，注意 Layer 的索引位置也有讲究：脚本里如果写死了1 << 8，那第 8 层必须是对应的名字，改层名不改索引没用。这种硬编码在老的射击 Demo 里非常常见，尤其是「只打敌人层」的射线掩码。

最后是 Physics 的碰撞矩阵和 Build Settings 的场景顺序。碰撞矩阵决定哪些层之间会产生物理交互，如果玩家和敌人在矩阵里被关掉了，子弹打上去不触发碰撞，表现为「明明瞄准了却打不中」。Build Settings 则决定打包后能进哪些场景，索引 0 是启动场景，这一项在编辑器里看不出问题，只有打包后才暴露。

4. 射击手感的三根支柱：射线命中、后坐力与对象池

4.1 为什么射击判定首选射线而不是物理子弹

射击游戏的命中判定有两条主流路线：物理子弹和射线检测（hitscan）。物理子弹是实例化一个带Rigidbody和Collider的物体，靠物理引擎推着飞，碰到东西触发碰撞回调；射线检测是每帧（或每次开火）从摄像机发一条射线，Physics.Raycast直接返回命中点。

物理子弹的问题是速度和精度不可兼得。子弹速度设成 200，物理步长默认 0.02 秒，一帧飞 4 米，薄墙和敌人的胶囊体很容易被整个跨过去，这就是常说的穿透。解决办法是给子弹开Continuous Dynamic碰撞检测，或者用Raycast在上一帧和这一帧位置之间补一条线段检测，两种做法都有额外开销。

射线检测没有穿透问题，一发一条线，命中点精确，开销也低。代价是「子弹飞行时间」这个手感要素没有了——开火即命中。所以短距离、快节奏的射击玩法普遍用射线，需要弹道下坠和飞行时间的狙击、投掷类才用物理子弹。

这份源码包里两种写法都可能出现。判断方法很简单：搜Physics.Raycast有结果，说明开火走射线；Prefabs目录下有Bullet预制体且带Rigidbody，说明还有一套物理子弹。两套并存时要注意它们是否共用同一个伤害接口，否则改伤害数值要改两处。

4.2 命中判定的落地实现与判定层配置

射线版的开火逻辑不长，但每一行都有对应的配置项，写错一行就是「打不中」或者「打自己」。

using UnityEngine; public class HitscanWeapon : MonoBehaviour { public Camera fpsCamera; // 射线起点，必须指向主摄像机 public float damage = 25f; // 单发伤害 public float range = 120f; // 有效射程，超出不判定 public LayerMask hitMask; // 只勾 Enemy 和 Default，务必取消 Player 层 public Transform muzzle; // 枪口，用于生成枪焰和拖尾 void Update() { // Fire1 依赖 Input Manager，缺轴会在按下时报错 if (Input.GetButtonDown("Fire1")) Fire(); } void Fire() { // 起点用摄像机而不是枪口，是为了让准星和弹道一致 Ray ray = new Ray(fpsCamera.transform.position, fpsCamera.transform.forward); RaycastHit hit; // QueryTriggerInteraction.Ignore：不把触发器当障碍物，避免打在空气上 if (Physics.Raycast(ray, out hit, range, hitMask, QueryTriggerInteraction.Ignore)) { // 用 GetComponentInParent 兼容碰撞体挂在子物体上的模型结构 var target = hit.collider.GetComponentInParent<IDamageable>(); if (target != null) target.TakeDamage(damage, hit.point, ray.direction); // 命中特效放在命中点和法线方向，保证贴花朝向正确 SpawnImpact(hit.point, hit.normal); } } void SpawnImpact(Vector3 point, Vector3 normal) { // 具体实现略：实例化火花预制体并朝 normal 方向对齐 } }

fpsCamera的赋值是最容易出错的一处。如果场景里有多个 Camera（比如武器视角的第二个相机），拖错了就会表现为「准星对着墙，子弹却打上天」。判断方法是运行后打开 Scene 视图，看 Game 视图对应的相机上有没有画出一条调试射线。

hitMask是第二个坑。默认值如果是Everything，射线会打在玩家自己的胶囊体上，第一发就命中自己，表现为「开火没反应但玩家掉血」。正确做法是在 Inspector 里把 LayerMask 改成只包含Enemy和Default，并且明确取消Player。这个字段漏配时不会报错，只能靠现象反推。

QueryTriggerInteraction.Ignore这一项在 5.3 之前的版本里没有，老代码里通常是Physics.Raycast(ray, out hit, range, hitMask)的三参重载，语义上默认就是忽略触发器。迁移到新版时如果报「参数不匹配」，把这一项去掉即可，或者显式补上。

GetComponentInParent<IDamageable>()这种写法依赖目标对象实现了一个统一的伤害接口。如果源码包里没有接口，各个敌人脚本各写各的hp字段，那就改成SendMessage("TakeDamage", damage)，但SendMessage有反射开销，敌人多的时候会掉帧。折中方案是给敌人加一个统一的DamageReceiver组件，内部再分发给具体脚本。

4.3 对象池：把 Instantiate/Destroy 从每帧里拿掉

射击游戏是对象创建的高频场景，一秒十发子弹，每发都Instantiate再Destroy，几十秒后就能看到 GC 峰值和帧率抖动。对象池的思路是把销毁改成「隐藏 + 归还」，从池里取而不是新建。

using System.Collections.Generic; using UnityEngine; public class BulletPool : MonoBehaviour { public static BulletPool Instance; // 简单单例，子弹自己归还时用 public GameObject bulletPrefab; // 子弹预制体，须带 Bullet 脚本 public int prewarmCount = 30; // 预热数量，按峰值同时在场数估 private readonly Queue<GameObject> pool = new Queue<GameObject>(); void Awake() { Instance = this; for (int i = 0; i < prewarmCount; i++) { var go = Instantiate(bulletPrefab, transform); go.SetActive(false); pool.Enqueue(go); // 关掉的物体不参与物理和渲染，开销极低 } } public GameObject Get(Vector3 pos, Quaternion rot) { // 池空时才扩容，扩容策略是「再建一批」而不是一个一个建 GameObject go = pool.Count > 0 ? pool.Dequeue() : Instantiate(bulletPrefab, transform); go.transform.position = pos; go.transform.rotation = rot; go.SetActive(true); return go; } public void Return(GameObject go) { go.SetActive(false); pool.Enqueue(go); } }

prewarmCount的取值有个经验公式：峰值同时在场子弹数 ≈ 每秒开火数 × 子弹存活时间（秒）。一秒开十发、子弹飞两秒，峰值就是二十，取三十留余量。预热太少会在开局瞬间触发扩容，预热太多浪费内存，对一个小 Demo 来说三十到五十都合理。

池化之后必须重置子弹状态。飞行中的子弹有速度、有旋转、可能还有个协程在倒计时，这些在SetActive(false)时不会自动归零。归还时如果不清速度，下一次取出来子弹会带着上一发的惯性飞向奇怪的方向。所以Return里在SetActive(false)之前要GetComponent<Rigidbody>().velocity = Vector3.zero，这一步老代码里经常漏。

还有一处：SetPositionAndRotation是较新版本才有的 API，老版本要拆成两行赋值。这不是功能差异，只是兼容性写法，拆开写在任何版本都能跑。

4.4 后坐力与散布的参数表

手感调参不需要改代码，全在参数上。下面这组是近距离快节奏射击的常用起点，具体数值要根据武器类型和敌人血量调：

调手感时一次只动一个参数，动完在同一个位置连开三梭子。同时改两个参数，出问题后说不清是谁的问题。这是踩过几次之后养成的习惯。

5. 五类高频翻车：从现象倒推原因与处置

5.1 现象一：场景一片粉色，控制台刷 Shader 报错

现象很直观：打开主场景，天空盒和 UI 正常，但所有模型、枪械、敌人全变成品红色，控制台里刷Shader error in '...'或者Material doesn't have a _MainTex property之类的信息。

原因分两种。一种是材质引用的 shader 在工程里不存在了，Unity 找不到就把材质渲染成粉色作为占位。老工程里常见的原因是用了Legacy Shaders/Diffuse这类旧内置着色器，新版里已被移除。另一种是 shader 存在但与当前渲染管线不兼容，比如工程从内置管线切到了 URP，而材质还用着Standard。

处置顺序是：先打开一个粉色材质的 Inspector，看 Shader 下拉框里显示的是什么。如果显示Hidden/InternalErrorShader，就把 Shader 改成Standard，再把贴图重新指到_MainTex上；如果显示的是Standard但依然粉色，那基本是管线不匹配，要么把整个工程切回内置渲染管线，要么用官方的材质升级工具批量转换。如果包里是模型贴图分离的结构，批量指认可以写个小编辑器脚本扫_MainTex字段，比手动点快得多。

还有一种伪装成粉色的问题：材质本身正常，但模型的MeshRenderer上Materials数组长度是零。这种在 Scene 视图里看是黑的，不是粉的，容易和着色器问题混淆，双击预制体看一眼 Inspector 就能区分。

5.2 现象二：点 Play 后人物往下掉 / 穿墙

点运行，玩家对象在场景里以肉眼可见的速度往下沉，或者一靠近墙就直接穿过去，掉出地图外面，控制台可能什么也不报。

先看玩家对象上挂的是CharacterController还是Rigidbody。如果是CharacterController但不往下掉反而悬空，说明它没有走重力逻辑，移动脚本可能只写了transform.Translate；如果是Rigidbody往下掉，多半是忘了勾Use Gravity之外的某项，或者角色脚底的Collider尺寸不对。

穿墙的原因通常是三件事之一：碰撞体没有附着在正确的层级上，墙的Collider被设成了Is Trigger；玩家移动用transform.position直接赋值，绕过了物理引擎的碰撞解算；或者玩家刚体的Collision Detection是Discrete，快速移动时用一帧跨过了薄墙。第二种最隐蔽，因为代码看起来完全正常，transform.Translate也确实移动了物体，只是物理系统对此一无所知。

处置方式：移动逻辑统一改用CharacterController.Move或Rigidbody.velocity，不要直接改transform.position；墙和地面的碰撞体确认不是 Trigger；如果必须高速移动，把刚体碰撞检测改成Continuous，或者在FixedUpdate里做移动。

5.3 现象三：子弹打不中，准星对着敌人也没反应

准星压在敌人身上，点击开火，没有命中特效、敌人不掉血、控制台不报错。这是排查成本最高的一类，因为它是静默失败。

第一层检查 LayerMask。把武器脚本的hitMask临时改成Everything再试一次，如果这时能打中，说明掩码配错了，通常是漏勾了敌人所在的层，或者层的索引位置不对。第二层检查射线的起点和方向，在Fire()里加一行Debug.DrawRay(ray.origin, ray.direction * range, Color.red, 2f);，运行后切到 Scene 视图看这条红线是不是从相机准星方向射出。如果方向偏了，多半是相机引用拖错。第三层检查碰撞体，敌人身上必须有Collider，且不能是Is Trigger——射线检测默认忽略触发器。

第四层是距离。老工程的range有时候被设成 10 或 20，而场景比例比想象中大，敌人站在三十米外，射线根本够不到。把range临时改成 1000 试一下就能排除。第五层最容易被忽略：射线的起点在相机位置，而相机可能被玩家胶囊体包住，第一发直接命中了玩家自己，表现为「敌人不掉血，玩家自己掉血」。这种情况把掩码里的Player层取消即可。

5.4 现象四：打包出来黑屏 / 只能跑第一关

编辑器里一切正常，打包成可执行文件后启动是黑屏，或者能进主菜单，点了开始却什么也不发生。

黑屏基本可以锁定为场景没进 Build Settings。Unity 打包时只包含 Build Settings 列表里的场景，列表为空时打包出来的程序没有任何可加载的场景，启动就是黑屏。打开 Build Settings，把主菜单和游戏场景按顺序拖进去，索引 0 是启动场景，确认它是主菜单。

「只能跑第一关」是另一回事。老代码里场景推进用的可能是Application.LoadLevel(Application.loadedLevel + 1)，迁移后如果场景列表顺序和原来不一致，或者新版本里loadedLevel的语义变了，就会加载到错误的场景甚至越界。改成按场景名加载更稳：SceneManager.LoadScene("Level02")，名字对不上会明确报错，比静默加载失败好排查。

还有一类是资源加载路径问题。老工程如果用了Resources.Load，而资源被放到了Resources文件夹之外，编辑器里能靠直接引用跑通，打包后引用会断。判断方法是打包后看Player.log，里面会有明确的NullReferenceException堆栈，比在编辑器里猜快得多。

5.5 现象五：连开几秒后帧率骤降

开局稳定 60 帧，按住开火键三秒后掉到 30 帧，停火一会儿又恢复。这种「越打越卡」的模式基本指向内存分配。

首要嫌疑是子弹的Instantiate和Destroy。每发子弹都新建一个 GameObject 并挂组件，销毁时产生垃圾，GC 触发时主线程停顿，表现就是周期性卡顿。用第 4 章的对象池替换掉，掉帧立刻消失。次要嫌疑是命中特效。每次命中实例化一个粒子预制体，粒子播完自动销毁，频率比子弹还高，如果没有池化，开销比子弹本身还大。

第三个嫌疑是GetComponent在Update里反复调用。子弹脚本里每帧GetComponent<Rigidbody>()拿速度，看起来只是一次调用，但子弹数量上来之后乘以帧率就是可观的数字。改成Awake里缓存一次，代码量不变，开销降一个量级。

第四个嫌疑比较隐蔽：字符串拼接。UI 上显示分数的代码如果写成scoreText.text = "Score: " + score;，每次更新都产生一个新字符串，分数变化频繁时会有持续的 GC 压力。用StringBuilder或者改成只在分数变化时更新，能缓解不少。

6. 上线前把难度曲线参数化，再跑一遍验收

老工程里的刷怪逻辑常常是硬编码的：前五波固定三个敌人，之后固定五个，速度写死。想调难度就得改代码、重新编译。更省事的做法是把参数抽成AnimationCurve，在 Inspector 里可视化拉曲线，改完不用重新编译。

using UnityEngine; public class WaveDirector : MonoBehaviour { public AnimationCurve spawnInterval = AnimationCurve.Linear(0f, 1.2f, 10f, 0.35f); public AnimationCurve enemySpeed = AnimationCurve.Linear(0f, 2.0f, 10f, 5.5f); public int baseCount = 4; // 第一波基础数量 public int addPerWave = 2; // 每波递增数量 public int maxAlive = 18; // 同时存活上限，防止刷爆 public float GetInterval(int wave) => spawnInterval.Evaluate(wave); public float GetSpeed(int wave) => enemySpeed.Evaluate(wave); public int GetCount(int wave) => baseCount + addPerWave * wave; }

AnimationCurve.Linear(起点波次, 起始值, 终点波次, 结束值)定义了一条从第 0 波到第 10 波的线性插值曲线。出怪间隔从 1.2 秒压到 0.35 秒，敌人速度从 2 提到 5.5，玩家能明显感觉到后期吃力但不会瞬间被压死。改成非线性曲线（比如先平后陡）可以在 Inspector 里直接拖关键帧，比在代码里调公式直观得多。

maxAlive是保险丝。如果没有它，第 15 波算出来的数量可能是 34，屏幕同时跑三十多个 AI，帧率直接崩，玩家体验变成卡顿而不是难。这个值按目标平台定，PC 端二十左右，移动端要再压。

最后是验收。我一般跑三条线：帧率、内存、包体。帧率在目标机型上跑三分钟，观察是否有周期性掉帧，有就回第 5 章查分配；内存看是否随时间单调上涨，上涨说明有对象没归还；包体看Editor.log里的资源列表，把没被引用的贴图、音频清掉，老工程里这类冗余往往占一半体积。

这个习惯是被坑出来的：早年间我改了刷怪曲线直接打包，结果第 12 波之后帧率掉到个位数，查了半天才发现是数量超限导致 AI 每帧都在做寻路。从那以后我每次调完难度参数，都会强制在目标机型上打一局到满波次，看帧率曲线和内存曲线，再决定这个数值能不能留。希望帮到你。

本文还有配套的精品资源，点击获取