第0章：你好，Python！

本章内容限 Windows 10+ 用户

0. 什么是Python？

Python 是一门让你用最少的代码做最多的事的编程语言。

它也是一门高度面向对象的高级编程语言——这意味着你写的每一段代码，本质上都是在和“对象”打交道，而不是直接操作内存地址。不过别担心，这个概念会在后面的章节中自然展开，现在你只需要记住这个名字。

在本章中，你不会学到任何语法，但你会获得三样比语法更重要的东西：

搭好环境：亲手配置一个干净、可复现的开发环境，避免后续 90% 的“在我机器上能跑”问题。
理解哲学：知道 Python 为什么这样设计，写出“地道”而非“能跑就行”的代码。
认清文件：知道 .py、.pyc、requirements.txt、__pycache__ 各自扮演什么角色，不再对着陌生后缀发懵。
认识工具箱：提前了解几个核心第三方库的名字和用途，后面用到时不会觉得从天而降。

这四样东西，是你从“看教程”到“自己写项目”的地基。

P.S. 如果你看不懂以上文本，你可以跳过它，后面将会自然展开。

1. 搭建 Python 环境：你的第一个“项目”

本节目标：配置一个隔离、干净、可复现的 Python 开发环境
预计用时：5~10 分钟
完成标志：在独立的虚拟环境中，成功运行代码。

Python 的环境配置可以很简单。你不需要版本管理器、不需要锁文件、不需要任何“现代工具链”——官方标配的工具已经完全够用。

1.1 下载与安装

如果你已经安装完了 Python，请跳过本段

下载时不必纠结哪种更专业，而是选择最适合的。

以下是推荐的几个下载链接

名称	优先级	链接	说明
清华大学开源软件镜像站	最高	https://mirrors.tuna.tsinghua.edu.cn/python	国内高速镜像站，速度最快最稳定
阿里巴巴开源镜像站	高	https://mirrors.aliyun.com/python-release/windows	清华大学镜像不可用时的替代方案
南京大学开源软件镜像站	较高	https://mirror.nju.edu.cn/python	校园网用户优先
官方源	较低	https://www.python.org/ftp/python	服务器在海外，网络不稳定

对于 Windows 10+ 用户，建议选择 Python 3.12.8

链接：Python 3.12.8 清华大学安装包

双击 .exe 文件后应该会看到如下界面：

此时需要确保勾选下方 Add python.exe to PATH

如果无需其他配置，请点击 Install Now，否则请点击 Customize installation。

选择 Customize installation 后，需一直点 Next，直到出现如下页面：

建议将路径改为非C盘目录，最好不使用空格和中文字符。

安装完成后，按下Win+R，输入powershell打开终端，输入如下命令：

python --version
# 应输出 Python 3.12.8 等类似信息

pip --version
# 应输出 pip 25.x.x from ...\Lib\site-packages\pip (python 3.12) 等类似信息

1.2 选一个顺手的编辑器

如果你已经安装编辑器，请跳过本段

Visual Studio Code（推荐）：轻量、插件丰富。安装官方 Python 扩展即可，开箱即用。
PyCharm Community（社区版）：专为 Python 设计的 IDE，调试和代码提示体验极佳，适合喜欢“全包圆”的读者。
绝对不要使用：Windows 记事本、Word。它们会插入隐藏字符和奇怪的引号，导致语法错误且极难排查。

1.3 虚拟环境（venv）：唯一需要遵守的“铁律”

这是本节唯一需要你建立“专业习惯”的地方。

永远不要在全局环境里 pip install。

如果所有项目都往全局装包，A 项目需要的 requests 2.20 和 B 项目需要的 requests 2.30 就会打架，最后你的 Python 环境会变成一锅粥，只能重装。

Python 官方自带了 venv 模块，一行命令就能创建隔离环境：

第一步：创建虚拟环境

在终端执行

C:
# 根据实际情况替换，如您的项目在D盘，需执行D:

cd 项目路径
# 替换为真实路径

python -m venv .venv

第二步：激活虚拟环境

在刚才那个终端执行

.venv\Scripts\activate.bat

如果是 PowerShell，执行

.venv\Scripts\Activate.ps1

激活后，你的终端提示符前面会多出一个 (.venv)，这就说明你进入了“隔离舱”。

第三步：验证虚拟环境

where python

输出的路径必须指向你刚才创建的 .venv 文件夹内部。如果是，恭喜你，现在你装任何包，都只会在这个文件夹里，绝不会污染系统。

（注：想退出隔离舱，只需在终端输入 deactivate 即可。）

2. 理解设计哲学：步入优秀开发者的第一步

本节目标：理解 Python 的核心设计原则，建立“Pythonic”的思维直觉。
预期耗时：15–20 分钟
完成标志：能分辨什么是“好代码”，并在写代码时有意识地遵循这些原则。
前置要求：已完成第 1 节环境搭建

很多教程把语法讲完才开始谈“哲学”，但 Python 的设计哲学不是锦上添花的装饰——它是这门语言的操作系统。不理解它，你写的只是“用 Python 语法的 C/Java 代码”；理解了它，你才真正开始写 Python。

2.1 Zen of Python：不是口号，是决策框架

在终端输入 import this，你会看到 Tim Peters 写的《Python 之禅》。别把它当鸡汤读，每一条都是工程决策的优先级排序：

Beautiful is better than ugly.          # 可读性 > 炫技
Explicit is better than implicit.       # 显式 > 隐式（魔法）
Simple is better than complex.          # 简单 > 复杂
Complex is better than complicated.     # 必要的复杂 > 不必要的繁琐
Flat is better than nested.             # 扁平 > 嵌套
Sparse is better than dense.            # 留白 > 拥挤
Readability counts.                     # 可读性是一等公民
Special cases aren't special enough to break the rules.  # 例外不应破坏规则
Although practicality beats purity.     # 实用主义 > 纯粹主义
Errors should never pass silently.      # 错误必须暴露
Unless explicitly silenced.             # 除非你明确选择忽略
In the face of ambiguity, refuse the temptation to guess.  # 歧义时拒绝猜测
There should be one-- and preferably only one --obvious way to do it.  # 唯一明显的方式
Now is better than never.               # 做比不做重要
Although never is often better than *right* now.  # 但匆忙不如等待正确方案
If the implementation is hard to explain, it's a bad idea.  # 难解释 = 坏设计
If the implementation is easy to explain, it may be a good idea.  # 易解释 ≠ 一定好，但值得考虑
Namespaces are one honking great idea -- let's do more of those!  # 命名空间是伟大的发明

看着像是天书，但最核心的只有3条：

1. Explicit is better than implicit（显式优于隐式）

代码的意图应该像白纸黑字一样清晰，而不是依赖读者的“脑补”或语言的特殊机制。

不可行：from module import * → 函数不知道是哪来的
可行：from module import foo → 清晰易懂，IDE可跳转
不可行：依赖全局变量传递状态 → 函数行为不可预测
可行：参数显式传入 → 签名即文档

总结：就像寄快递必须写清收件人地址和电话，不能指望快递员靠“默契”猜出来。代码中的每一个依赖、每一个数据来源，都应该在当前位置直接可见，而不是藏在某个看不见的角落里。

2. Readability counts（可读性是一等公民）

代码被阅读的次数远多于被编写的次数。写给机器看的代码能跑就行，写给人看的代码才能维护。

不可行：x = [i for i in range(100) if i % 2 == 0 and i > 10] → 一行塞入过多逻辑，大脑需要拆解
可行：拆成多行 + 有意义的变量名 → 每一步的筛选意图一目了然
不可行：变量命名 a, tmp, flag → 三天后自己都不知道代表什么
可行：变量命名 user_count, temp_buffer, is_authenticated → 名字本身就是注释

总结：就像写文章要分段、加标题、留白一样，代码也需要呼吸感。好的代码读起来像散文，坏的代码读起来像加密电报。三个月后的你，就是那个最需要被善待的“读者”。

3. Practicality beats purity（实用主义优于纯粹主义）

Python 不追求理论上的完美，它追求的是“让人最快解决问题”。

不可行：为了“纯函数”强行避免所有副作用，导致代码绕了五层抽象
可行：如果一行命令式代码比三层抽象更清晰，就用命令式
不可行：项目刚起步就按企业级架构设计，过度封装
可行：脚本 → 模块 → 包 → 框架，按需升级复杂度

总结：就像做饭不必每次都从磨面粉开始，能用现成的面条就别自己擀。Python 允许你在“正确”和“快”之间做权衡，只要这个权衡是有意识的、可解释的。

不要背诵，更不必纠结时回来查表。Zen of Python 本身就是人类认知习惯的提炼——当你面对两种写法犹豫不决时，那个让你读起来更顺、想得更少的选择，就是答案。需要刻意解释才能自圆其说的写法，无论多“优雅”，都是反人类的。

2.2 PEP 8：让哲学落地的操作手册

如果说 Zen of Python 是宪法，那 PEP 8 就是具体的法律法规。

PEP 8 是 Python Enhancement Proposal #8，即 Python 官方代码风格指南。它规定了缩进、命名、空行、注释等细节，目的是让全社区的代码看起来像同一个人写的。遵守 PEP 8 不是为了讨好谁，而是为了降低所有人的认知负荷。

以下列举常用的风格规范：

符号两侧需写空格

错误示例：a=1，紧凑，无呼吸感

正确样例：a = 1，让代码有呼吸感，不紧凑

命名遵循约定俗成的格式

错误示例：getUserName / MAXretry，风格混杂，一眼无法识别标识符类型

正确样例：

user_name = "name"
def get_name():
    return "name"
# 变量、函数用 蛇形命名法，即 name_name_name

class GetUserScore:
    pass
# 类用 驼峰命名法，即 NameNameName

MAX_USER = 5
# 常量用 全大写蛇形命名法，即 NAME_NAME_NAME

导入语句分组且排序

错误示例：import requests, os, sys 混写在一行，来源不清、顺序混乱

正确样例：

import sys    # 先导入内置库
import os

import request    # 再导入第三方库
import numpy

import my_module    # 最后导入本地模块

顶层定义之间保留两个空行

错误示例：函数/类紧挨着写，视觉上糊成一团，找不到边界

正确样例：顶层函数或类之间空两行，方法之间空一行，结构自带导航

def get_user_name():
    return "user_name"


def get_user_age():
    return "user_age"


a = 1


class AddTwoNumber:
    def __init__(a: int, b: int):
        self.a = a
        self.b = b

    def add() -> int:
        return a + b

单行不超过推荐长度

错误示例：一行塞下 120+ 字符，阅读时必须横向滚动，上下文断裂

正确样例：控制在 79–88 字符内，必要时换行对齐，视线自然流动，无需左右扫视
类型注解保持简洁一致

错误示例：def add(a, b): 参数和返回值全靠猜，或 def add(a: int, b) -> int: 标一半漏一半，风格割裂

正确样例：
```
def add(a: int, b: int) -> int:
    return a + b


def get_user(user_id: int) -> dict[str, str] | None:
    ...
```
要么全标，要么不标；用新语法 X | Y 代替 Union[X, Y]，减少视觉噪声
字符串引号统一且避免转义

错误示例：msg = "it's ok" / path = 'C:\\Users\\name' 引号混用、反斜杠满天飞，阅读时频繁解码

正确样例：
```
msg = "it's ok"          # 内含单引号时用双引号
path = r"C:\Users\name"  # Windows 路径加 r 前缀
sql = """
    SELECT *
    FROM users
    WHERE id = ?
"""                      # 多行文本用三引号，保留格式
```
项目内选定一种引号风格（推荐双引号），遇到冲突时切换另一种以减少转义
布尔判断直接使用真值测试

错误示例：if len(items) == 0: / if flag == True: 冗余比较，把 Python 当 C 写

正确样例：
```
if not items:       # 空列表/字典/字符串/None 均为 falsy
    ...

if flag:            # 布尔变量直接判断
    ...

if value is None:   # 仅检查 None 时用 is，不用 ==
    ...
```
利用 Python 的真值规则，代码更接近自然语言：“如果没有数据”而非“如果数据长度等于零”
异常处理精确捕获，禁止裸 except

错误示例：except: / except Exception: 吞掉所有错误，调试时像大海捞针

正确样例：
```
try:
    result = data[key]
except KeyError:
    result = default_value

try:
    value = int(text)
except (ValueError, TypeError) as e:
    logger.warning("转换失败: %s", e)
    value = 0
```
只捕获你能处理的特定异常，其余让它自然抛出；需要记录时用 as e 绑定，不要丢弃上下文
注释解释“为什么”，而非“是什么”

错误示例：x += 1 # x 加 1 / # 遍历列表 复述代码本身，信息量为零

正确样例：
```
# 跳过首行表头，从第二行开始解析数据
for row in rows[1:]:
    ...

# 重试上限设为 3 次：超过后下游服务会触发熔断
MAX_RETRIES = 3
```
代码说“怎么做”，注释说“为什么这么做”；如果一段代码需要注释才能看懂逻辑，优先重构代码本身

3. 认清文件角色：从代码编写者到工程构建者的分水岭

本节目标：了解各种 Python 文件、文件夹的作用
预计用时：5~10 分钟
完成标志：能初步了解常见的 Python 文件。

很多教程把文件后缀当作环境配置的细枝末节，但 Python 的文件体系不是项目结构的附属品——它是这门语言运行机制的物理显影。不理解它，你只是在机械地管理一堆陌生后缀；理解了它，你才真正看懂 Python 是如何在磁盘上呼吸与运转的。

面向新手，我们可以把 Python 官方文件简化为“写代码的”、“电脑自动生成的”和“打包发布的”三类。以下是精简后的核心清单：

1. 你亲手写的源码文件

.py：标准源代码。就是你平时写 Python 代码的文件，默认用 UTF-8 编码保存。文件名就是模块名，所以别用中文或特殊符号命名。
.pyw：无控制台窗口的脚本（Windows 专属）。内容和 .py 完全一样，但双击运行时不会弹出黑色命令行窗口。专门用来写带图形界面（GUI）的小工具，避免用户看到碍眼的黑框。注意：它只在 Windows 下有效，Linux/macOS 会把它当普通 .py 处理。
.pyi：类型提示文件。只写函数签名和类型注解，不写具体实现。相当于给代码贴“说明书”，方便编辑器智能提示和静态检查，运行时 Python 会直接忽略它。

2. 解释器自动生成的文件

__pycache__/ 文件夹：Python 3 的缓存目录。每次导入模块时自动生成，里面装着编译好的字节码。
.pyc：字节码缓存。藏在 __pycache__/ 里，作用是让下次导入同一个模块时更快。删了也没事，Python 会自动重新生成。
.so / .pyd：C 语言扩展模块。有些底层功能（比如 os、json）是用 C 写的，编译后在 Linux/macOS 上是 .so，Windows 上是 .pyd。你可以像普通模块一样 import 它们。

3. 包与项目结构文件

__init__.py：包的身份证。放在文件夹里，告诉 Python “这是一个包，不是普通目录”。可以是空文件，也可以在里面写包的初始化代码。
__main__.py：包的启动入口。当你用 python -m 包名 运行时，Python 就会找这个文件来执行。想让包能像命令一样运行，就靠它。
pyproject.toml：现代项目配置文件。现在官方推荐用它来声明项目依赖、版本、构建工具等信息，一个文件搞定以前好几个文件的活。
.whl：安装包。相当于 Python 的“exe 安装程序”，别人装你的库时直接用这个，不用重新编译，又快又省事。

4. requirements.txt：项目依赖的“购物清单”

requirements.txt 是 pip 工具约定的依赖清单文件，Python 解释器本身不识别它，仅由 pip 读取。

格式规范

每行记录一个第三方库及版本约束，常见写法如下：

requests==2.31.0         # 精确锁定版本
flask>=2.0.0             # 最小版本约束
django                   # 无版本约束（不推荐）
numpy~=1.24.0            # 兼容版本约束

核心作用

通过以下命令一键安装所有依赖：

pip install -r requirements.txt

实现环境复现，保证开发、测试、生产环境的依赖一致性，消除“在我机器上能跑”的问题。

生成方法

使用 pip freeze 导出当前环境的所有包：

pip freeze > requirements.txt

重要前提：必须在独立的虚拟环境中执行，否则会将全局 Python 环境中的无关包一并导出，造成依赖膨胀。

新手三条原则

永远配合虚拟环境使用
在项目目录下创建隔离环境，避免污染系统 Python，也避免将系统工具包误写入 requirements.txt。
不要手动编造版本号
手动写入的版本号可能在实际环境中不存在，或与其它包产生冲突。除非你明确知道版本边界，否则优先使用 pip freeze 锁定。
区分运行依赖与开发依赖
测试框架、代码格式化工具、类型检查器等开发阶段使用的工具，应单独存放于 requirements-dev.txt，与生产运行依赖分离。

现代替代趋势

较新的项目开始转向 pyproject.toml 统一声明项目元数据与依赖，配合 uv.lock 或 poetry.lock 实现精确锁定。但由于 requirements.txt 格式简单、零学习成本且被所有 pip 用户原生支持，它依然是小项目和入门阶段最实用、最广泛的依赖管理方案。

4. 理解第三方库：从重复实现到借力复用的分水岭

什么是第三方库

第三方库是别人写好的代码，你直接拿来用。就像装修房子时买现成的家具，不用自己砍树做桌子。

为什么要认识它们

新手常见的两个极端：

不知道有现成工具，什么都自己写
听说某个库很火，不管合不合适就直接用

认识工具生态，就是在“完全无知”和“盲目乱用”之间找到平衡点。

几个几乎必用的库

以下库会在后续内容中反复出现，先混个脸熟：

requests：发 HTTP 请求，比如调用 API、抓取网页
openpyxl：读写 Excel 文件
pandas：处理表格数据，比 Excel 能处理更大的数据量
flask：写 Web 服务，几行代码就能搭一个接口
pillow：处理图片，裁剪、缩放、格式转换

怎么找库

当你想做某件事时，先问一句：“有没有现成的库？”然后去 PyPI 搜索关键词，或者直接搜“python 做xxx 库”。

这一阶段的目标

不是背下所有库的名字，而是建立一种意识：遇到需求，先找现成的轮子，再考虑自己造。

5. 本章结语

走到这里，你已经完成了四件比写代码更重要的事。

第一，你亲手搭建了一个干净、隔离的开发环境，知道什么是虚拟环境、为什么它如此重要——这让你后续的学习不会因为“环境崩了”而卡住。

第二，你理解了 Python 的设计哲学，知道“显式优于隐式”“可读性是一等公民”“实用主义优于纯粹主义”这三条原则会伴随你整个编程生涯。

第三，你看清了 Python 文件体系的角色分工，不再对着 .pyc、__pycache__、requirements.txt 发懵——知道哪些文件是你要写的，哪些是电脑自动生成的，哪些是给包管理工具用的。

第四，你认识了几个最常用的第三方库，知道遇到需求时“先找轮子，再造轮子”，而不是凭空硬写。

这四样东西，在本章中你只是“知道”了它们。未来在你真正写代码时，它们会从知识点变成习惯，从习惯变成直觉。到那时，你才算真正入了 Python 的门。

现在，你已经不再是一个对着命令行手足无措的初学者，而是一个手上有环境、心里有原则、脑中有地图的开发者了。

下一章，我们将开始写真正的 Python 代码——你拥有一个干净的环境，懂得 Python 的设计哲学，清晰了解文件体系，知道应该用什么库，接下来唯一要做的，就是写起来。

by 澜湾
by LanWan