next_permutation必须从升序开始，因为它基于当前排列找字典序紧邻的下一个排列；若起始非最小序（如{3,1,2}），会跳过前面所有排列，导致结果不全。
next_permutation 为什么必须从升序开始？
因为 next_permutation 是“找下一个字典序更大的排列”，不是“生成全部排列”。它依赖当前序列的顺序状态——只有当前是某个排列 P，它才能基于 P 找到紧邻的下一个 P'。如果起始不是最小字典序（即升序），你会直接跳过前面大量排列，甚至第一次调用就返回 false（比如从降序开始）。
- 错误做法：
vector<int> v = {3,1,2}; next_permutation(v.begin(), v.end());</int>→ 只得到 {3,2,1}，漏掉 {1,2,3}→{1,3,2}→{2,1,3}→… 全过程 - 正确做法：先
sort(v.begin(), v.end())，再进循环调用next_permutation - 对自定义类型，必须确保
operator 正确定义字典序逻辑，否则比较结果错，排列顺序就乱
字符串字典序全排列要小心空格和大小写
next_permutation 对 std::string 同样有效，但它按 char 的 ASCII 值比较：大写字母（A–Z: 65–90）排在小写字母（a–z: 97–122）前面。所以 "Ba" 字典序小于 "ab"，但直觉上可能以为不是。
- 常见错误现象：输入
"abC"，排序后是"Cab"（因为'C'），接着生成的排列以 <code>C开头为主，不是按“不区分大小写”或“自然排序”预期 - 若需忽略大小写排序，得预处理：统一转小写做排序/比较，但注意原字符串仍要保留大小写参与排列 —— 这时不能直接用
next_permutation，得手写比较器或改用索引排列 - 含空格、标点时同理：
' '（32）比所有字母都小，会强制排最前
性能瓶颈往往不在 next_permutation 本身
next_permutation 平均时间复杂度是 O(1)，最坏 O(n)，非常快。真正拖慢的，通常是循环体里的操作：比如每次排列都构造新字符串、触发内存分配、或做高成本校验。
- 避免在循环里写
string s(v.begin(), v.end())—— 改用引用或原地操作 - 不要在每轮里调用
cout ：I/O 是数量级级慢操作，调试时可先存到 vector，最后批量输出 - 若只关心满足某条件的第一个排列（如“首个大于给定值的排列”），记得找到就
break，别硬跑完全部 n! 个 - 注意：n ≥ 12 时，12! = 479001600，即使每纳秒处理一个，也要 0.5 秒；n=14 就超 870 亿，实际已不可穷举
替代方案：手写 DFS 排列生成更容易控制边界
当需要剪枝、限制长度、跳过重复元素、或配合其他约束（如“相邻差不超过 k”）时，next_permutation 很难介入。这时候用递归 DFS + used 标记反而更直观、可控。
立即学习“C++免费学习笔记（深入）”；
-
next_permutation天然去重？不。它对重复元素照常生成重复排列，除非你先sort再手动跳过相邻相同值（易错） - DFS 示例骨架：
void dfs(vector<int>& nums, vector<bool>& used, vector<int>& path) { if (path.size() == nums.size()) { /* 处理结果 */ return; } for (int i = 0; i < nums.size(); ++i) { if (used[i] || (i > 0 && nums[i] == nums[i-1] && !used[i-1])) continue; used[i] = true; path.push_back(nums[i]); dfs(nums, used, path); path.pop_back(); used[i] = false; } } - DFS 缺点是栈深度和代码量略增，但灵活性和可读性在复杂条件下明显占优
很多开发者卡在“为什么没生成全”或“顺序不对”，其实问题不出在 next_permutation 本身，而在于初始状态没归位、字符比较逻辑被忽略、或者根本选错了工具场景。
