leetcode 所有题目默认要求以 class solution: 形式组织代码，这是平台自动评测系统的硬性接口约定——它并非鼓励你学习 oop，而是为标准化输入/输出调用提供统一入口，必须严格遵循，不可省略或改写。
leetcode 所有题目默认要求以 class solution: 形式组织代码，这是平台自动评测系统的硬性接口约定——它并非鼓励你学习 oop，而是为标准化输入/输出调用提供统一入口，必须严格遵循，不可省略或改写。
在 LeetCode 上刷题时，你看到的几乎每道 Python 题目起始模板都是：
class Solution:
def functionName(self, param1: type1, param2: type2) -> returnType:
# your code here
return result这不是编程风格建议，而是强制执行的契约接口。原因如下：
✅ 为什么必须用 class Solution？
LeetCode 后端采用统一的沙箱执行机制：它会动态导入你的提交文件，然后通过反射（reflection）查找名为 Solution 的类，并调用其中指定名称的方法（如 twoSum、lengthOfLongestSubstring）。例如，对输入 ["2","7","11","15"] 和 target=9，系统实际执行的是：
sol = Solution() result = sol.twoSum([2,7,11,15], 9) # → 必须能这样调用！
若你改为函数式写法：
def twoSum(nums, target): # ❌ 不会被识别
...或删去类结构：
# ❌ 无类、无方法定义 → 提交报错 "NameError: name 'Solution' is not defined"
系统将无法定位入口，直接判定为编译错误（Compile Error），甚至不进入逻辑测试阶段。
⚙️ 类型注解（如 s: str、-> int）的作用
这些是 PEP 484 类型提示（Type Hints），属于可选但强烈推荐的增强实践：
- ✅ 帮助 IDE 实现智能补全与参数检查；
- ✅ 提升代码可读性与协作性；
- ✅ LeetCode 测试器本身不依赖类型运行（Python 是动态类型语言），但部分题目（如涉及 List[int]）需正确导入：
from typing import List # 若使用 List, Dict 等泛型，必须显式导入
? 常见误区与注意事项
- 不要重命名 Solution 类：改成 class MySolver: 或 class Leet: 会导致判题失败；
- 不要省略 self 参数：即使方法不依赖实例状态，def func(self, ...) 是必需语法；
- 避免全局变量污染：多测试用例连续执行，类实例可能复用，切勿在 __init__ 中缓存跨用例状态（除非题目明确要求）；
- 可安全忽略 __init__：99% 的题目无需自定义构造函数，直接实现目标方法即可。
? 实际开发中的启示
这种设计模拟了真实工程场景中的“服务接口”思维：
你提供的不是一个脚本，而是一个可被外部系统按协议调用的模块化组件。
虽非典型 OOP 应用（多数解法无状态、无继承），但它训练你关注接口契约（interface contract）——即“给什么输入，保证返回什么输出”，这正是 API 设计、单元测试和系统集成的核心素养。
✅ 正确模板示例（带必要导入）
from typing import List, Optional
class Solution:
def twoSum(self, nums: List[int], target: int) -> List[int]:
seen = {}
for i, x in enumerate(nums):
complement = target - x
if complement in seen:
return [seen[complement], i]
seen[x] = i
return []总结：class Solution 是 LeetCode 的“运行时门面”，不是教学陷阱，而是工程化约束。接受它、理解它、熟练使用它——这一步本身，已是迈向专业编码者的第一课。
