企业官网建设流程全解析

简介：基于C#与Unity实现的2D跑酷闯关对战冒险游戏设计压缩包，面向初学Unity引擎或需要完成课程设计的开发者。项目样例为《忍者小狐》，是一款横板闯关冒险类小游戏：玩家操控狐狸角色，借助路上小动物的帮助，躲避危险与陷阱、对抗敌人，同时收集钻石道具以开启最终战斗；关卡在保证可通关的前提下设计了随机障碍物机关，兼顾休闲性与挑战性。压缩包约52.18MB，内含课程设计论文报告、答辩PPT与完整Unity源码，可结合Unity2018及以上版本和Visual Studio 2017以上环境，系统学习C#脚本逻辑与游戏流程控制。已有2275人学习/下载，资源完整覆盖从项目背景、玩法设计、核心代码到答辩展示的完整链路，重点展示随机机关、最终房间武器对战，以及不同道具碰撞带来的生命计数与钻石收集机制，是2D闯关冒险类课程设计的落地参考范本。

1. 拿到C#+Unity的2D跑酷闯关对战包，先别按Play，先当工程拆

拿到“基于C#+unity实现的2D跑酷闯关对战冒险游戏设计.zip”这个包，最忌讳的是解压、拖进Unity、直接按Play，然后卡在第一屏报错里翻车。这类工程包的真正价值不在于“能跑”，而在于它用C#把2D跑酷、闯关、对战、冒险四条玩法线拧成了一组可复现的代码结构：角色怎么起跳、障碍怎么刷、敌人伤害框怎么判定、关卡进度存哪里，全是能照着改的答案。它适合刚学完C#语法、想看看真实Unity脚本怎么组织的新手，也适合想快速产出作品集但不想从空场景搭起的求职者。前提很简单：用Unity Hub按对版本打开，然后逐个模块改参数，而不是指望双击就出成品。

2. 从zip到可运行工程：先核对Unity版本，再顺着场景反推C#脚本挂载

2.1 打开项目前的三分钟检查：ProjectVersion文件、包管理器和编译日志

这类跑酷项目zip打开后，目录结构千差万别，但Assets、Packages、ProjectSettings这三个文件夹是所有Unity工程的标准外观，少一个都说明解压不完整或下载过程坏了包。第一次打开前别急着双击.unity场景文件，先做三件事。

第一，用记事本打开ProjectSettings/ProjectVersion.txt，看到类似“m_EditorVersion: 2021.3.1f1”的一行，这就是作者记录下来的Unity版本。Unity Hub里点“添加项目”，选中包含Assets和ProjectSettings的那一层作为项目根目录，然后让Unity自动导入。如果本机装的编辑器版本和ProjectVersion.txt差很多，Console窗口会直接给“Opening project in non-matching editor version”的警告，后面出现的任何API报错都要优先怀疑是版本升级导致的，而不是代码本身写错。

第二，打开Window → Package Manager看项目都依赖了哪些包。2D跑酷项目通常只需要2D Sprite、2D Physics、TextMeshPro这类默认包。如果看到Cinemachine或Input System，说明代码里多半用了新输入系统，运行时如果报“InvalidOperationException: You are trying to read Input using the old input system, but the new input system is active”，就是输入系统的Active Input Handling没有切换，去Project Settings → Player → Active Input Handling改成Both或者New Input System即可。

第三，把Console窗口停在编译完成的那一刻。真正的报错集中在编译结束后的前十几行：脚本里引用了不存在的类、预制体上挂着已经删除的脚本，都会在这里标红。我的原则是：编译错误清零之前，不进场景看效果。

2.2 顺着Inspector反推脚本挂载：场景层级就是这份工程的目录索引

编译通过后，先打开Assets/Scenes下的主场景，在Hierarchy面板里把整个物体树展开。跑酷类项目的场景层级通常会沿着一套约定俗成的骨架：GameManager挂在空物体上负责流程存档，Player是一个带着Sprite、Rigidbody2D、Collider2D和若干C#脚本的角色物体，Camera身上挂着摄像机跟随脚本，再往下是Spawner、UI和背景容器。

点开Player对象看Inspector，你会看到一串脚本组件，脚本名就是C#类名。比如挂着一个叫PlayerController的脚本，字段区里有moveSpeed、jumpForce、groundCheck、groundLayer这些可拖拽项，那这个工程的手感参数基本都在这里调，不用进代码。顺着脚本名去Assets/Scripts里找同名.cs文件，就能把“场景里的物体”和“C#代码里的类”一一对应起来，这是读任何陌生Unity工程都最快的入口。

我一般会再做一个动作：把所有带“（Script）”的组件名抄成一张纸，在旁边标注它的更新频率。比如PlayerController在Awake里取组件、Update里读输入、FixedUpdate里做物理移动，CameraFollow只在LateUpdate里执行，那这个工程的帧率瓶颈大概率就在这两个脚本的调用顺序上。读代码时也先看字段区域，再看Awake、Start、Update、FixedUpdate几个生命周期谁做了什么，别一上来啃方法体。

2.3 写一个Editor体检脚本，一键找出预制体里的空引用

场景能打开不等于玩法能跑通，跑酷项目最容易在“预制体引用断掉”这件事上翻车：敌人预制体改了脚本名，场景里没更新；图集重导后Sprite引用丢失，角色直接显示成空物体。这种问题不会在编译时报错，而是要等游戏运行到生成敌人的那一刻才炸。与其被黑匣子折磨，不如写个Editor脚本一次性扫完所有预制体。

把下面这段代码放在Assets/Editor/PrefabHealthCheck.cs，Unity会自动把它识别成编辑器扩展脚本：

using UnityEditor; using UnityEngine; public class PrefabHealthCheck : EditorWindow { [MenuItem("Tools/Prefab 体检")] public static void Check() { string[] guids = AssetDatabase.FindAssets("t:Prefab"); int missingCount = 0; foreach (string guid in guids) { string path = AssetDatabase.GUIDToAssetPath(guid); GameObject prefab = AssetDatabase.LoadAssetAtPath<GameObject>(path); if (prefab == null) continue; // 遍历预制体上所有组件，包括隐藏的子物体 foreach (Component comp in prefab.GetComponentsInChildren<Component>(true)) { if (comp == null) { Debug.LogWarning($"预制体 {path} 存在缺失脚本，右键组件槽选择 Remove Missing Scripts"); missingCount++; } } } Debug.Log($"体检完成，共发现 {missingCount} 处缺失脚本"); } }

AssetDatabase.FindAssets用“t:Prefab”过滤出全项目预制体，然后逐个加载并遍历组件。关键判断是comp == null：当脚本文件被删除或类名被修改后，Unity会保留这个组件槽但内容变成空引用，编辑器里显示成灰色图标，运行时不触发编译错误但会丢掉一串初始化代码。执行方式是点击菜单栏Tools → Prefab 体检，把Console里的Warning逐个清掉再进游戏。顺手加载所有预制体这个操作在引擎切换阶段会慢几秒，但换来的是游戏运行时不炸，值得。

3. 把2D跑酷手感调对：碰撞检测、摄像机跟随和地图生成这样落地

3.1 Rigidbody2D的四个参数就是手感本体，别急着写代码

很多拿到这个zip的人第一件事是去改跳跃高度数值，但手感不对的根源经常在Rigidbody2D组件本身。2D跑酷的手感九成来自物理参数而非脚本逻辑，这四个地方必须逐个确认。

Collision Detection Mode默认是Discrete离散检测，角色速度一提上去就容易穿透平台，后面避坑章会细说，先把高速角色切到Continuous。Interpolate插值建议选Interpolate，否则角色在1080P高刷屏上跑动时轮廓会有可见的顿挫感。Constraints里把Freeze Rotation Z勾上，否则角色斜着撞上障碍物会直接转体翻车，这在跑酷里是毁灭性的。Gravity Scale是跳跃手感的分水岭，默认1.0会让跳跃显得“飘”，跑到2.0到2.5之后落地更脆、起跳更快，配合跳跃力度一起微调，每改一档就进游戏跳三次感受曲线。

交互逻辑用C#脚本控制，下面是这个包最核心的PlayerController写法，我把输入读取和物理赋值放进了不同的生命周期：

using UnityEngine; [RequireComponent(typeof(Rigidbody2D))] public class PlayerController : MonoBehaviour { [Header("跑动参数")] public float moveSpeed = 8f; public float jumpForce = 12f; [Header("地面检测")] public Transform groundCheck; // 脚底的一个空物体 public float checkRadius = 0.05f; public LayerMask groundLayer; // 只勾选地面所在层 private Rigidbody2D rb; public bool IsGrounded { get; private set; } void Awake() { rb = GetComponent<Rigidbody2D>(); } void Update() { // 输入读取放 Update：按键事件在 FixedUpdate 里可能被跳过 if (Input.GetButtonDown("Jump") && IsGrounded) { // 只覆盖 y 轴速度，保留水平方向的惯性 rb.linearVelocity = new Vector2(rb.linearVelocity.x, jumpForce); } } void FixedUpdate() { float h = Input.GetAxisRaw("Horizontal"); // 直接赋值速度而非加力，跑酷需要即时响应 rb.linearVelocity = new Vector2(h * moveSpeed, rb.linearVelocity.y); IsGrounded = Physics2D.OverlapCircle(groundCheck.position, checkRadius, groundLayer); } }

这里的逻辑顺序值得解释：Update先读跳跃输入，FixedUpdate再做水平速度赋值和落地检测。如果把Input.GetButtonDown放进FixedUpdate，玩家在快速连点跳跃时会有明显丢输入，因为FixedUpdate的调用频率不跟屏幕刷新率走。跳跃时只写y轴速度而保留x轴速度，是为了避免起跳瞬间水平速度被清零。地面检测用Physics2D.OverlapCircle在脚底画一个小圆，半径0.05到0.1足够，groundLayer只勾地面层，防止角色踩着敌人头顶无限二段跳。moveSpeed初值8、jumpForce初值12是常见起点，手感偏重的项目可以把Gravity Scale和moveSpeed一起上调。

3.2 摄像机跟随别在Update里直接改位置，用LateUpdate加平滑阻尼

跑酷游戏里摄像机是玩家的眼睛，跟随做不好，再好的手感也会被镜头抖碎。常见的错误是把摄像机绑成Player的子物体，角色一跳跃摄像机跟着上下颠，碰到PlatformEffector边缘时还会继承旋转，镜头直接歪掉。正确做法是独立脚本跟随，而且必须在LateUpdate里改位置。

using UnityEngine; public class CameraFollow : MonoBehaviour { public Transform target; public float smoothTime = 0.12f; public Vector3 offset = new Vector3(0f, 1.5f, -10f); public float lookAheadX = 2f; private Vector3 velocity; void LateUpdate() { if (target == null) return; Vector3 targetPos = target.position + offset; // 按角色水平速度给镜头加前瞻量，跑得快看得远 float vx = target.GetComponent<Rigidbody2D>().linearVelocity.x; targetPos.x += Mathf.Clamp(vx * 0.1f, -lookAheadX, lookAheadX); transform.position = Vector3.SmoothDamp( transform.position, targetPos, ref velocity, smoothTime ); } }

LateUpdate保证摄像机移动发生在所有物体Update完成之后，避免出现“角色先动、摄像机下一帧才追上”的错位感。SmoothDamp的smoothTime是镜头追角色的松弛时间，0.12到0.15秒手感比较跟手，小于0.08会硬得像锁定，大于0.2会头晕。offset的z轴必须是-10，Unity 2D相机的默认正交视野是从z轴负方向看向场景的，写成正数会把场景整个裁掉。lookAheadX给镜头增加了水平前瞻：角色往右跑时镜头会多露出右侧一段路，这是跑酷游戏让玩家提前看到下一个平台的标准手法。验证方法很直接：让角色跑到最大速度跳一次，看屏幕两侧有没有露出场景外的黑边，有就加大相机的orthographicSize或者把背景Sprite加宽一倍。

3.3 地图生成用对象池加PerlinNoise，别让垃圾回收拖垮帧率

无限跑酷的地图生成，最常见的错误写法是每帧Instantiate新平台、跑出屏幕就Destroy，运行三十秒后GC频繁触发，帧率曲线像心电图。这个项目里更稳的做法是对象池加PerlinNoise：提前把平台实例化进一个Queue，随用随取，回收到左侧后复用。

using System.Collections.Generic; using UnityEngine; public class PlatformSpawner : MonoBehaviour { public Transform player; public GameObject platformPrefab; public int poolSize = 30; public float spawnX = 12f; public float despawnX = -14f; public float minGap = 2f; public float maxGap = 6f; public float minHeight = -1f; public float maxHeight = 3f; private Queue<GameObject> pool = new Queue<GameObject>(); private float lastSpawnX; void Start() { for (int i = 0; i < poolSize; i++) { GameObject go = Instantiate(platformPrefab, Vector3.zero, Quaternion.identity); go.SetActive(false); pool.Enqueue(go); } lastSpawnX = player != null ? player.position.x : 0f; SpawnOne(lastSpawnX + Random.Range(minGap, maxGap)); } void Update() { if (player == null) { Debug.LogWarning("PlatformSpawner 没拖 Player 引用"); return; } // 角色没到生成边界就继续铺平台 while (lastSpawnX < player.position.x + spawnX) { lastSpawnX += Random.Range(minGap, maxGap); // PerlinNoise 生成连续起伏的高度，避免随机数导致断崖连片 float h = Mathf.PerlinNoise(lastSpawnX * 0.3f, 0f); SpawnOne(new Vector2(lastSpawnX, minHeight + h * (maxHeight - minHeight))); } // 回收左侧出屏的平台 foreach (GameObject go in pool) { if (go.activeSelf && go.transform.position.x < player.position.x + despawnX) go.SetActive(false); } } void SpawnOne(Vector2 pos) { if (pool.Count == 0) return; GameObject go = pool.Dequeue(); go.transform.position = pos; go.SetActive(true); pool.Enqueue(go); } }

对象池的核心思路是预热：启动时一次性创建poolSize个平台全部隐藏，生成时从队首取出、放置、激活、塞回队尾，用Dequeue和Enqueue完成轮转，全程零Instantiate、零Destroy，GL不会出现持续攀升的峰值。PerlinNoise在这里的作用是替代Random.Range生成高度，它输入一个连续x坐标会返回0到1的连续值，所以相邻平台的高度是平滑过渡的，不会出现前一个平台在三米高、下一个直接掉到地底的悬崖断档。lastSpawnX乘以0.3是频率系数，越大起伏越剧烈，平台竞速关可以调到1.5以上，普通闯关关用0.3左右。回收判断用despawnX这个负值，意思是“平台位置比角色左移14米就隐藏”，这是为了让整条生成链路循环起来。

4. 闯关、对战、冒险三层玩法：状态机、伤害判定和C#存档的联动写法

4.1 用枚举加C#委托做玩家状态机，攻击中不能跳、受击不能动

跑酷和对战结合后，玩法规矩开始叠加：攻击动作不能中途起跳，受击有一段无敌时间，死亡状态下所有输入失效。如果用一堆bool变量互相约束，加一个新状态就要改三个地方，最后谁都说不清角色到底能不能动。这里最常见的做法是枚举加switch的状态机，把“能不能切换状态”的规则集中在一处。

using System; using UnityEngine; public enum PlayerState { Idle, Run, Jump, Attack, Hit, Dead } public class PlayerFSM : MonoBehaviour { public PlayerState currentState = PlayerState.Idle; // C#委托：状态切换时广播事件，动画和音效各自订阅，互不耦合 public event Action<PlayerState> OnStateChanged; public void ChangeState(PlayerState next) { if (next == currentState) return; currentState = next; OnStateChanged?.Invoke(next); } void Update() { switch (currentState) { case PlayerState.Idle: // 检测到水平输入时切到 Run break; case PlayerState.Run: // 持续移动，按攻击键切到 Attack，按跳跃切到 Jump break; case PlayerState.Jump: // 落地后按移动状态切回 Idle 或 Run break; case PlayerState.Attack: // 攻击动画播完通过事件回调切回 Idle break; case PlayerState.Hit: // 无敌帧结束后切回 Idle break; case PlayerState.Dead: // 关闭输入，把角色交给 GameManager 处理胜负结算 break; } } }

状态机只做一件事：决定“当前状态能不能切到下一个状态”。Attack期间禁止Jump，直接在ChangeState调用前加判断；Hit期间禁止移动，因为switch分支根本没写移动逻辑。这样玩法规则收敛在一个方法里，而不是散落在七八个Update方法中。C#委托OnStateChanged在这里是解耦关键：动画系统订阅它播放奔跑或攻击动画，音效系统订阅它播放跳跃或受击音效，互相不知道对方存在，后期加一个状态不需要回头改动画控制器的每个参数。用委托广播状态而不是直接调用动画组件，这是C#里事件驱动思想第一次在游戏项目里落地的位置，值得在代码注释里标清楚。

4.2 对战的伤害判定：Hurtbox和Hitbox分属不同图层，配合无敌帧防连扣血

对战系统里伤害判定不能依赖角色之间的碰撞体直接接触，否则敌人碰到玩家就开始扣血，跑动中蹭一下掉三次血是常有的事。正确结构是分两层：受击方身上挂Hurtbox，攻击方攻击时挂Hitbox，双方互不接触，只有Hitbox碰到Hurtbox才结算。

using UnityEngine; public class Damagable : MonoBehaviour { public int maxHP = 100; public float invincibleTime = 0.5f; private int currentHP; private bool isInvincible; public System.Action OnDamaged; public System.Action OnDead; void Start() { currentHP = maxHP; } public void TakeDamage(int damage) { if (isInvincible || currentHP <= 0) return; currentHP -= damage; OnDamaged?.Invoke(); if (currentHP <= 0) { OnDead?.Invoke(); return; } // 无敌帧：防止贴脸状态下反复触发伤害 isInvincible = true; Invoke(nameof(EndInvincible), invincibleTime); } void EndInvincible() { isInvincible = false; } }

攻击方脚本里只需要一个OnTriggerEnter2D方法：判断进入的是否为受击方层级，读取伤害数值，调用TakeDamage。这里唯一的坑是图层碰撞矩阵：在Project Settings → Physics2D → Layer Collision Matrix里，把敌人Hitbox所在的EnemyAttack层设为只碰撞Player层，玩家攻击框所在的PlayerAttack层只碰撞Enemy层。如果不分层，攻击判定框会撞到角色自己的本体或者自己的攻击框，出现攻击挥空但自己掉血的灵异现象，这是做对战玩法最典型的血泪经验。无敌帧的时长通常取250到500毫秒，配合受击闪白反馈：在OnDamaged里把SpriteRenderer的color改亮一点，半秒后恢复，一套完整的受击反馈就齐了。

4.3 关卡配置用ScriptableObject，玩家进度用C#序列化JSON，分开管

项目标题里“闯关”和“冒险”意味着两套数据：关卡设计数据和玩家进度数据。如果把平台间隔、敌人数量直接写死在Spawner脚本里，换一关就要该代码重新编译。把每一关的可调参数抽成ScriptableObject资产才是更稳的做法。

using UnityEngine; [CreateAssetMenu(fileName = "LevelConfig", menuName = "Game/LevelConfig")] public class LevelConfig : ScriptableObject { public int levelIndex; public float platformGapMin; public float platformGapMax; public int enemyCount; public float timeLimit; public Sprite backgroundSprite; }

在Project窗口右键Create → Game → LevelConfig，就能为每一关生成一个配置资产，Inspector里改数值，存档时不会把配置写死进二进制。GameManager在加载关卡时读取当前关卡索引，把配置里的platformGapMin和platformGapMax传给PlatformSpawner覆盖默认值。ScriptableObject在这里的核心价值是：让数值调整不经过编译，美术和策划可以独立干活，代码只需要认准关卡索引这一个入口。

玩家进度就别用ScriptableObject了，那是编辑期资产，运行时写入不持久。进度用JSON序列化文件，才算是给玩家一个真正的存档。用JsonUtility加StreamWriter实现一个存档读写，注意指定UTF8编码避免中文名乱码：

using System; using System.IO; using System.Text; using UnityEngine; [Serializable] public class SaveData { public int currentLevel; public int coins; public string playerName; } public class SaveManager : MonoBehaviour { private string saveFilePath; void Awake() { saveFilePath = Path.Combine(Application.persistentDataPath, "save.json"); } public void Save(SaveData data) { string json = JsonUtility.ToJson(data, true); File.WriteAllText(saveFilePath, json, new UTF8Encoding(false)); } public SaveData Load() { if (!File.Exists(saveFilePath)) { return new SaveData(); // 首次运行返回默认存档 } string json = File.ReadAllText(saveFilePath, new UTF8Encoding(false)); return JsonUtility.FromJson<SaveData>(json); } }

Application.persistentDataPath是Unity给每个平台分配的合法写入目录，Windows下在用户AppData里，Android下在应用私有目录，开发者不需要手工拼接磁盘路径。JsonUtility是Unity对C# JSON序列化的内置实现，要求目标类打[Serializable]标记，字段必须是public或标了[SerializeField]。它不支持Dictionary，如果存档里有键值对需求，要先转成List再序列化。UTF8Encoding(false)的含义是不带BOM，这对跨平台读取更安全。这一整套下来，“闯关进度”和“冒险存档”就被分成两个互不干扰的模块：编辑器里配数据，运行时写进度，玩家重装游戏前存档都在本地待着。

5. 常见翻车点排查：碰撞穿透、摄像机抖帧和打包后失控的处理

5.1 高速跑动直接穿墙：Collision Detection Mode还停在Discrete

现象：角色吃到加速道具后速度冲到15以上，面对一排普通平台直接穿过去，BoxCollider2D像是不存在一样，偶尔还会卡在墙体一半的位置抖两下再弹出来。

原因：Unity 2D物理默认的Collision Detection Mode是Discrete离散检测，每个物理步进只检测一次物体当前位置是否与其他碰撞体重叠。角色移动速度足够快时，一帧的位移距离超过了平台碰撞体的厚度，引擎会认为物体这一帧“跳过”了障碍物而没有记录相交。速度越快、碰撞体越薄，越容易穿透。

解决：选中角色、敌人的Rigidbody2D组件，把Collision Detection Mode从Discrete改成Continuous。这个模式会让物理引擎在两步之间做连续扫描，只要本帧位移路径与碰撞体有交集就能拦住。代价是高强度Continuous会让物理运算时间上升，不要把场景里所有静态地面的碰撞体都切成Continuous，只给高速移动的玩法和弹幕类物体开。如果单个平台碰撞体本身太薄，把多个相邻平台的BoxCollider2D合并成一个EdgeCollider2D，既省钱又防穿。

5.2 摄像机抖帧和对象池怪物残留：都是生命周期没对齐

现象：角色横向跑动时，背景平台出现每秒几次的小碎步抖动，体感像丢了帧；从对象池里刚刷出来的敌人一半血量没回复，上一次被砍掉的HP还挂在身上。

原因：摄像机抖帧十次里有八次是更新顺序问题，在Update里直接改摄像机位置，又在FixedUpdate里改角色位置，两个循环频率不齐，镜头每一步都在追一个还没落定的目标。对象池残留则是回收对象在SetActive(false)时没有重置状态，池子只负责“物理上”把对象藏起来，“逻辑上”的血量、速度、动画状态还留在上一次死亡时的样子。

解决：统一按“输入在Update、物理在FixedUpdate、摄像机和UI在LateUpdate”这个顺序调整脚本。尤其摄像机，从Update挪到LateUpdate，再把SmoothDamp的smoothTime保持在0.12秒以上，抖感立即消失。对象池这边，在所有进入池子的物体身上写OnDisable方法，在里面重置血量、速度、Sprite颜色、协程，最后把自己SetActive(false)。OnDisable是Unity生命周期函数，SetActive切换时必触发，比手动在回收处重置状态可靠，这套组合拳打完，池子里出来的每个敌人都是出厂状态。

5.3 打包后翻车：存档中文乱码、微信小游戏不适配和平台宏定义

现象：编辑器里跑得好好的，Build成Windows或Android独立包后，玩家名字和关卡名全部变成问号；按官方步骤把项目转成微信小游戏，角色点击无响应。

原因：编辑器环境的默认代码页和打包后运行环境的代码页不一致，写存档时用的是系统默认编码，读档时系统编码变了，中文直接损坏。微信小游戏则需要专用的运行环境和不支持部分本地文件读写接口的WebGL逻辑，在编辑器里根本没走过那些分支。

解决：写文件时显式指定UTF8编码，不给系统默认编码做主的机会，这是最稳的一行代码：

using System.IO; using System.Text; // 写存档固定 UTF8 编码，编辑器、Windows、Android 行为一致 File.WriteAllText(saveFilePath, json, new UTF8Encoding(false));

微信小游戏平台在Unity里需要先从Build Settings把目标切到WebGL，导出WebGL包后再用微信开发者工具转换上传，不是直接把Windows包拿来改后缀。输入这块也要单独做平台分支，比如多点触控判断用Input.GetTouch而不是Input.GetMouseButtonDown。用平台宏定义把不同运行环境下的逻辑隔离开，是很标准的做法：

using UnityEngine; public class PlatformHelper : MonoBehaviour { void Start() { #if UNITY_WEBGL Debug.Log("WebGL / 微信小游戏：存档改用 PlayerPrefs"); #elif UNITY_STANDALONE Debug.Log("PC 独立包：存档走 JSON 文件"); #endif } }

#error和#if这些预编译指令要留意作用域，宏定义只影响当前平台编译，Android和Windows的输入差异也能用UNITY_ANDROID、UNITY_STANDALONE开启。排查这类问题速度最快的套路是：先确认Build Settings里当前平台图标激活没激活，再确认宏分支内代码没有语法错误，最后看存档目录路径是否落在Target平台允许写的区域。

6. 发布前最后一道工序：用Profiler数据把帧率钉在60，顺手做掉两个常见优化

6.1 先开Profiler承认瓶颈在哪，再决定动哪块代码

跑酷游戏性能调优最忌讳拍脑袋：觉得卡就降画质，觉得慢就删特效，全凭感觉最后往往白忙。正确顺序是Window → Analysis → Profiler，选中CPU Usage，跑三分钟正常关卡，把曲线数据截图，然后只处理这三项：

6.2 图集和遮挡剔除是2D跑酷性价比最高的两道工序

2D场景里贴图数量巨大，每个Sprite单独提交给GPU会让DrawCall爆炸。在Window → 2D → Sprite Atlas里新建图集，把Sprites文件夹里的散贴图全拖进去，Sprite的Packing Mode选择Atlas即可。另一个容易被忽略的点是Sprite Renderer的Sorting Order：跑酷场景里平台、角色、背景三层各设一组连续的数字，避免渲染顺序靠物体在世界中的y坐标猜来猜去。

遮挡剔除在2D正交场景里不明显，但如果项目里夹带了3D模型或者多层视差背景，可以把场景物体拆成近远景两批：近处平台和敌人走动态渲染，远处背景烘焙成静态批次。双面材质shader和模型遮挡剔除插件这类优化在2D跑酷里属于锦上添花，先把图集和物理静态合并做完，帧率通常已经回到60。

我的个人习惯是改完任何物理参数后不急着继续做下一关，先挂机跑三分钟Profiler看曲线：Physics.Process稳定在3ms以内、GC Alloc没有尖峰，才算真的放心。跑酷这种高频物理游戏，优化不是炫技，是替玩家的设备保帧率。希望帮到你。

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