sort_values降序必须显式设ascending=false；多列排序时ascending需等长列表；inplace=true易引发隐性bug；nan默认排末尾，用na_position控制位置。
sort_values 降序排序必须显式设 ascending=False
很多人以为不写 ascending 参数就默认升序，其实没错——但降序必须主动写 ascending=False，不写或传 None 都不会自动变成降序。Pandas 的 sort_values 默认值就是 True，这点容易被忽略，导致排序结果和预期相反。
常见错误现象：df.sort_values('age') 看起来“没排错”，但其实是升序；想看年龄最大的在最前，却得到最小的在最前。
-
df.sort_values('score', ascending=False)→ 按 score 降序 -
df.sort_values(['class', 'score'], ascending=[True, False])→ class 升序、score 降序 - 传字符串
'False'或布尔值0都无效，必须是 Python 布尔False
多列混合排序时 ascending 必须长度匹配
当按多列排序（如先按部门升序，再按工资降序），ascending 如果是单个布尔值，会统一应用到所有列；如果要分别控制，就必须传列表，且长度必须和列名列表一致，否则抛出 ValueError: Length of ascending must match length of columns。
使用场景：报表导出时经常需要“大类升序 + 小类降序”，比如部门 A 的高薪员工排前面，部门 B 的高薪员工排后面。
- 正确：
df.sort_values(['dept', 'salary'], ascending=[True, False]) - 错误：
df.sort_values(['dept', 'salary'], ascending=[False])→ 长度为 1，但列有 2 个 - 错误：
df.sort_values(['dept', 'salary'], ascending=False)→ 所有列都降序，不是混合逻辑
inplace=True 不返回新 DataFrame，但原地修改有风险
加 inplace=True 看似省事，但容易引发隐性 bug：如果后续代码还依赖原始顺序（比如索引对齐、分组位置、绘图坐标），改了就回不去了。更麻烦的是，某些链式操作中 inplace=True 会失效（例如 df.query(...).sort_values(..., inplace=True) 实际不生效）。
性能影响：原地修改看似省内存，但 Pandas 内部仍可能触发 copy-on-write 机制，实际收益有限；而显式赋值 df = df.sort_values(...) 语义清晰、调试友好。
- 推荐写法：
df = df.sort_values('time', ascending=False) - 避免写法：
df.sort_values('time', ascending=False, inplace=True) - 注意：
inplace=True对视图（view）可能报SettingWithCopyWarning，尤其在切片后排序时
NaN 值默认排在末尾，需用 na_position 调整
默认情况下，sort_values 把 NaN 当作最大值处理，降序时出现在最前？不对——它其实排在最后（无论 ascending=True 还是 False）。这个行为常让人困惑，尤其是想把缺失数据集中查看时。
可选值只有两个：'first' 或 'last'（字符串，不是布尔值），不支持其他写法。
- 让 NaN 排最前：
df.sort_values('price', ascending=False, na_position='first') - 让 NaN 排最后（默认）：
na_position='last'可省略 - 错误写法：
na_position=True或na_position=0→ 报ValueError
真实项目里，财务数据或用户填写字段常含大量 NaN，不显式控制 na_position，排序后第一眼看过去全是有效值，反而漏掉空值分布情况。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
