Python可通过封装、配置分离、协议抽象和结构化输出等习惯自然预留扩展空间：函数/类拆分逻辑、关键字参数、配置外置、鸭子类型+Protocol、日志/异常/返回值设计均服务于“改得少、错得少、读得懂”。
Python 本身不强制要求你为未来需求做设计，但通过合理
用函数和类封装行为，而不是写一长串脚本
把逻辑拆成小单元，比如“读配置”“发请求”“存结果”，每个功能独立成函数或方法。未来要加新格式支持（如从 JSON 改成 YAML），只需改一个函数，不影响其他部分。
- 避免把所有逻辑堆在
if __name__ == "__main__":里 - 函数参数尽量用关键字参数（
def process(data, timeout=30, retry=True)），方便以后加新选项而不破坏调用 - 类的接口保持稳定：内部实现可换，但方法名和输入/输出约定别轻易动
配置与代码分离
把可能变的东西（如 API 地址、重试次数、路径）抽到配置文件（config.py 或 settings.toml）或环境变量里。下次要换环境或调试，不用翻代码，直接改配置。
- 用
os.getenv("API_TIMEOUT", "30")代替硬编码30 - 配置项命名清晰，比如
MAX_RETRY_ATTEMPTS比retry更易理解意图 - 加个简单校验（如类型、范围），提前暴露配置错误，而不是运行到一半才崩
留好接口缝：鸭子类型 + 协议（Protocol）或抽象基类（ABC）
当不确定未来会接入什么数据源或处理器时，先定义“它该能做什么”，而不是“它必须是什么类”。Python 的鸭子类型天然支持这点，配合 typing.Protocol 可让 IDE 和类型检查器也帮上忙。
- 例如定义
class DataReader(Protocol): def read(self) -> dict: ...，之后无论是 CSVReader 还是 DBReader，只要实现read就能传进去 - 不用一开始就写 ABC，等真出现两个以上相似实现时再抽象，避免过早设计
- 函数参数类型注解用协议而非具体类，比如
def load(reader: DataReader)
日志、异常和返回值留出观察点
未来需求常来自“出了问题怎么查”或“要统计什么”。提前打点日志、区分异常类型、让函数返回结构化结果（比如字典或 dataclass），比事后补救容易得多。
- 关键步骤加
logger.info("Fetched %d items from %s", count, source)，而不是只在出错时才记 - 自定义异常（如
class ValidationError(Exception)），比全用ValueError更利于后续捕获和处理 - 函数别只返回
True/False，考虑返回{"success": True, "data": ..., "warnings": [...]}，给后续加字段留余地
