Python 3.x 文件编码更健壮，因其严格分离 str（Unicode 文本）与 bytes（原始字节），强制在 I/O 边界显式指定 encoding，避免 Python 2.x 的隐式解码和静默乱码。
str）和字节（bytes）彻底分离，并强制在 I/O 边界做显式编码/解码**。Python 2.x 混用 str 表示文本和字节，导致“隐式解码”频繁触发，一碰非 ASCII 就容易抛 UnicodeDecodeError 或静默乱码。
str 和 bytes 类型严格区分
Python 2.x 的 str 是字节容器，unicode 才是文本；而 Python 3.x 的 str 默认就是 Unicode 文本，bytes 才是原始字节。
- 读文件时，
open()默认以文本模式返回str，必须指定encoding参数（如encoding='utf-8'），否则会用系统默认编码（Windows 上常是cp1252），出错立刻暴露 - 若你真要操作字节，得显式用
open(..., 'rb')，返回bytes，不会自动尝试解码 - Python 2.x 中
open().read()返回str，但后续调用.decode()常被遗忘或位置错误，容易在字符串拼接、正则、写入时崩
open() 函数默认要求 encoding 参数
Python 3.x 的 open() 在文本模式下不接受缺失 encoding 的安全假设——它不会回退到 locale 编码并静默容忍错误。
- 没传
encoding时，它仍会用locale.getpreferredencoding()，但一旦遇到无法解码的字节（比如 UTF-8 文件里混了 GBK 字节），就直接报UnicodeDecodeError，而不是像 Python 2.x 那样让str带着损坏字节继续跑 - 你可以主动控制容错：用
errors='ignore'或errors='replace'，但这是你明确选择的策略，不是语言替你瞎猜 - 对比 Python 2.x：
open().read()返回str，后续.decode('utf-8')可能放在循环外、条件分支里，或压根没写——问题延迟到下游才爆发
print() 和 input() 不再隐式编解码
Python 2.x 的 print 语句和 raw_input() 对编码处理模糊；Python 3.x 的 print() 和 input() 全部基于 sys.stdout.encoding 和 sys.stdin.encoding，且会在编码失败时清晰报错。
-
print(中国)在 Python 3.x 中只要终端支持 UTF-8 就能正常输出；在 Python 2.x 中，print u'中国'可能因sys.stdout编码未设好而崩，或静默变成'\xe4\xb8\xad\xe5\x9b\xbd' -
input()返回的是已解码的str，不是原始字节流，避免了手动.decode()的遗漏风险 - 如果标准流编码异常（如重定向到文件且未设 encoding），Python 3.x 会提前在
print()调用时报UnicodeEncodeError，而非让数据在日志或网络传输中悄悄变乱码
UnicodeDecodeError 看似麻烦，实则是把 Python 2.x 里那些藏在日志末尾、API 响应体、数据库字段里的乱码问题，提前拉到眼前解决。 
