python 3的str类型直接以unicode码点存储，所有文本操作均在unicode层进行，无需运行时反复decode/encode；而python 2的str本质是字节串，需频繁显式编解码，易出错且低效。
str 类型直接以 Unicode 码点存储，无需运行时反复 decode/encode —— 这是 Python 3 处理 Unicode 更高效的根本原因。
Python 2 的 str 不是文本，是字节串
你在 Python 2 里写 s = "中文"，得到的是 str 类型，但它本质是 UTF-8 编码的字节（比如 b'\xe4\xb8\xad\xe6\x96\x87'），不是“中文”这个概念本身。每次要做文本操作（比如正则匹配、切片、大小写转换），都得先 s.decode('utf-8') 变成 unicode 对象；写入文件或网络又得再 .encode() 回去。这个过程重复、隐式、容易漏，且每次调用都涉及内存拷贝和编码查表。
Python 3 的 str 就是 Unicode 文本
Python 3 中 s = "中文" 直接创建一个 str 对象，内部存的是 U+4E2D 和 U+6587 两个码点，所有字符串操作（s.upper()、s.split()、re.sub()）都直接在 Unicode 层进行，不涉及编码转换。
python-script-generator
下载
快速生成专业的 Python 脚本和应用代码。一键创建完整项目结构，支持CLI、API、爬虫、Bot、Django等多种项目类型，包含完整的项目结构、配置文件、依赖管理、测试、README和文档。
- 不需要显式
.decode()才能当文本用 -
.encode('utf-8')只在需要字节输出时才调用一次（如写文件、发 HTTP 请求） - 避免了 Python 2 中常见的
UnicodeDecodeError和UnicodeEncodeError链式报错 - 字符串拼接、格式化（包括
f"{x}"）全程在 Unicode 层完成，无隐式转换开销
open() 默认行为差异暴露真实瓶颈
Python 2 的 open("data.txt").read() 返回 str（字节），你必须自己决定怎么 decode；Python 3 的 open("data.txt").read() 默认按系统 locale 解码成 str（Unicode），省掉一次手动 decode —— 但这只是表象。真正高效的地方在于：一旦解码完成，后续所有文本处理都不再触碰编码逻辑。
- 错误做法：
open("utf8.txt").read().encode('utf-8').decode('gbk')（Python 2 风格套娃） - 正确做法：
open("utf8.txt", encoding="utf-8").read()→ 得到干净str，后续任意处理 - 如果文件编码不确定，用
open("data.bin", "rb")读出bytes，再用chardet.detect()判断后单次.decode()，而不是反复 encode/decode
bytes 和 str 分离带来确定性
Python 3 强制区分 bytes 和 str，看似增加了显式转换要求，实则消除了大量运行时类型猜测和隐式转换开销。比如：
-
"a" + b"b"直接报TypeError，而不是 Python 2 那样尝试隐式 decode 再拼接（结果不可控、性能差） -
json.loads()输入必须是str（UTF-8 文本），不会接受bytes并偷偷 decode —— 行为可预测 - HTTP 库（如
requests）返回的.text是str，.content是bytes，边界清晰，不用猜数据状态
bytes 没有 self-describing 能力，b'\xe4\xb8\xad' 既可能是 UTF-8 的“中”，也可能是 GBK 的“涓”。这一步没法靠语言设计优化，只能靠上下文或 chardet 这类探测库。Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
