服务器端 vs 客户端

• 服务器脚本置于 ServerScriptService 中 — 切勿信任客户端数据
• LocalScript 置于 StarterPlayerScripts 或 StarterGui 中 — 仅在客户端运行
• 使用 RemoteEvent 实现“发送即忘”（fire-and-forget）通信；若需服务器返回值，则使用 RemoteFunction
• 务必在服务器端进行校验 — 客户端可发送任意数据，外挂用户一定会利用这一点

安全性

• 绝不可信任客户端输入 — 所有数据均须在服务器端校验
• 服务器端合理性检查 — 玩家是否有权限？数值是否合理？
• FilteringEnabled 始终启用 — 但它无法保护你的 RemoteEvent
• 切勿通过 RemoteEvent 暴露管理员命令 — 权限检查必须在服务器端完成

DataStore

• :GetAsync() 和 :SetAsync() 可能失败 — 需用 pcall 包裹，并配合退避重试策略
• 速率限制：60 + numPlayers × 10 次请求/分钟 — 写入操作应排队，尽可能批量处理
• 使用 :UpdateAsync() 执行读-改-写操作 — 避免竞态条件
• 会话锁定（Session locking）— 防止玩家重连时数据丢失，建议结合 :UpdateAsync() 与显式状态检查实现
• 在 Studio 中启用 API 访问进行测试 — 设置 → 安全 → API 服务

内存泄漏

• 信号连接未断开 — 应保存连接句柄并在不再需要时调用 :Disconnect()
• 实例移除后应调用 :Destroy() — 此操作将自动设 Parent 为 nil 并断开所有绑定事件
• 玩家离开时未清理资源 — 使用 Players.PlayerRemoving 事件执行清理逻辑
• 表中持有无用引用 — 对不再需要的引用显式赋值为 nil

角色（Character）处理

• 玩家加入时（PlayerAdded）角色可能尚未生成 — 应使用 player.CharacterAdded:Wait() 或监听 CharacterAdded 事件
• 角色重生意味着新角色实例 — 需在每次 CharacterAdded 时重新绑定事件
• Humanoid.Died 在角色死亡时触发 — 适用于死亡逻辑处理
• 可调用 LoadCharacter() 强制重生 — 但通常更推荐依赖自然重生机制

复制（Replication）

• ServerStorage：仅服务器可见 — 客户端无法访问
• ReplicatedStorage：服务器与客户端均可访问 — 用于共享模块与资源
• ReplicatedFirst：在客户端最先加载 — 适用于加载界面等场景
• Workspace 会复制到客户端 — 但服务器始终拥有权威（authority）

服务（Services）模式

• 使用 game:GetService("ServiceName") 获取服务 — 避免直接索引（如 game.ServiceName），因其在不同上下文中可能失败
• 缓存服务引用 — 如 local Players = game:GetService("Players")
• 常用服务：Players、ReplicatedStorage、ServerStorage、RunService、DataStoreService

RunService

• Heartbeat：在物理模拟之后运行 — 适用于大多数游戏逻辑
• RenderStepped：仅客户端可用，在渲染前执行 — 适用于相机控制、视觉更新等
• Stepped：在物理模拟之前运行 — 适用于物理系统干预
• 避免每帧执行高开销计算 — 应将其分摊至多个帧中执行

常见错误

• wait() 已弃用 — 请使用 task.wait() 以获得可靠的时间控制
• spawn() 已弃用 — 请改用 task.spawn() 或 task.defer()
• require 返回已缓存的模块 — 多次 require 返回同一张表，修改将被共享
• :Clone() 不会触发事件 — 若需触发，须手动调用对应事件
• 即使 CanCollide 设为 false，部件仍可能触发 Touched 事件 — 如需完全禁用触碰检测，请使用 CanTouch