Unity类中Serialized Fields与Public变量声明顺序规范咨询

Unity引擎本身没有强制要求类成员必须按固定顺序编写，但是结合行业通用协作约定和编辑器使用逻辑，排序核心原则是优先按「使用场景」排序，其次再按访问修饰符排序，而非单纯按public/Serialized/private的访问权限优先级排。

序列化字段与公共变量的优先级判定 #

两种字段的排序优先级不看是[SerializeField]修饰的私有字段，还是public字段，核心看它会不会显示在Inspector面板、是否需要编辑器配置：

• 所有会被Unity序列化、显示在Inspector中需要手动配置的字段，不管是public默认序列化的，还是[SerializeField]修饰的非public字段，都归为同一优先级，放在所有字段的最前面。
• 加了[NonSerialized]特性的public字段，本质是运行时给其他脚本调用的状态值，不会显示在Inspector里，不需要提前配置，不应该和可配置字段放在一起。

你目前把所有Public Vars放在最前面的习惯，在单人小项目里用完全没问题，但在团队协作场景下有明显问题：会把需要美术/设计师配置的公共参数，和运行时才会赋值的公共逻辑变量混在一起，非程序协作者打开脚本根本分不清哪些字段是要配的，很容易出现漏配、错改参数的问题。

行业通用的推荐排序（绝大多数商业Unity项目通用） #

从上到下按顺序编写即可，Unity生命周期函数单独提出来放在方法最前面，方便快速找执行入口：

• 第一类：Inspector可配置序列化字段
  • 按面板显示顺序排列，可搭配[Header]分组，内部先写[SerializeField]修饰的非public字段，再写无[NonSerialized]的public可配置字段
• 第二类：非序列化运行时字段
  • 先写加了[NonSerialized]的public运行时变量，再写private/protected级别的内部缓存、组件引用、状态变量
• 第三类：Unity生命周期方法
  • 按Awake→OnEnable→Start→Update/FixedUpdate→OnDisable→OnDestroy的执行顺序排列
• 第四类：公共方法
  • 对外暴露的接口，按功能模块分组排列
• 第五类：私有方法
  • 内部逻辑实现，按调用顺序排列即可

参考示例 #

public class PlayerController : MonoBehaviour
{
    // 序列化可配置字段
    [Header("移动参数")]
    [SerializeField] private float moveSpeed = 5f;
    [SerializeField] private float jumpForce = 12f;
    [Header("战斗参数")]
    public int maxHealth = 100;

    // 非序列化运行时字段
    [NonSerialized] public int currentHealth;
    private Rigidbody _rb;
    private bool _isGrounded;

    // 生命周期方法
    private void Awake()
    {
        _rb = GetComponent<Rigidbody>();
        currentHealth = maxHealth;
    }
    private void Update()
    {
        CheckGround();
        Move();
    }

    // 公共方法
    public void TakeDamage(int damage)
    {
        currentHealth -= damage;
        if (currentHealth <= 0) HandleDeath();
    }

    // 私有方法
    private void CheckGround()
    {
        _isGrounded = Physics.Raycast(transform.position, Vector3.down, 0.1f);
    }
    private void Move()
    {
        // 移动逻辑省略
    }
    private void HandleDeath()
    {
        gameObject.SetActive(false);
    }
}

补充：如果是个人独立开发，只要你自己能快速找到对应成员，任何排序规则都可以，规范本身是为了降低协作时的沟通成本，不是必须死守的教条。

内容的提问来源于stack exchange，提问作者Ninquiet