std::stack 是括号匹配检查的首选容器，因其天然支持后进先出（lifo）逻辑，能安全高效地处理入栈、配对与判空，避免越界风险和冗余复杂度。
为什么 std::stack 是括号匹配检查的首选容器
因为括号匹配本质是后进先出（LIFO）行为：遇到左括号入栈，遇到右括号必须和栈顶左括号配对。用 std::stack 能天然反映这一逻辑，且避免手动管理索引或迭代器越界风险。
常见错误是用 std::vector 模拟栈但误用 back() + pop_back() 时没判空，导致 std::out_of_range；或者用 std::string 当栈存字符，却忘了 empty() 判定时机不对——必须在每次读到右括号前检查栈是否为空。
- 始终在调用
top()或pop()前用empty()判空 - 不要用
std::deque或std::list替代——无必要增加复杂度 - 若需记录位置信息（如报错行号），可改用
std::stack<:pair int>></:pair>，但基础检查无需额外开销
如何处理嵌套、混合括号（()、[]、{}）
关键不是“支持多种括号”，而是建立左右括号的映射关系，并确保每种右括号只匹配对应类型的左括号。不能简单统计数量相等就认为合法——[{]} 就是典型反例。
实操建议用 std::unordered_map 预定义右括号到左括号的映射，例如：{')': '(', ']': '[', '}': '{'}。遍历时：左括号直接入栈；右括号先查映射表，再比对栈顶是否一致。
- 映射表用
char键值足够，别用std::string——性能差且易写错长度 - 遇到未知字符（如
@或中文括号）应跳过或报错，取决于需求；默认建议跳过，避免干扰主逻辑 - 若输入含转义字符（如
"\("），需提前预处理，否则会被当作真实左括号——这是实际项目中最常被忽略的点
std::string 遍历中容易漏掉的边界情况
最典型的坑是字符串末尾残留未匹配左括号——循环结束时栈非空，但很多人只检查匹配失败就 return false，忘了最后还要 return stack.empty();。
另一个高频问题是把 for (char c : s) 和 for (size_t i = 0; i 混用：前者无法获取下标用于定位错误位置，后者若配合 <code>s.at(i) 可能抛异常，而 s[i] 不检查越界。
- 必须在循环结束后加
return stack.empty();，否则"((("会误判为 true - 如需返回错误位置，用索引遍历 +
size_t类型，避免int下溢（当s.length()>INT_MAX时） - 空字符串
""应返回 true，这是多数语法检查器的共识，别额外加if (s.empty()) return true;——stack.empty()已覆盖
要不要支持自动补全？C++ 标准库不提供，得自己攒
C++ 本身没有“自动补全”运行时能力；所谓补全，其实是分析不匹配位置后，根据栈状态推断缺什么。比如栈里剩 '(' 和 '['，当前字符是 '}'，说明前面缺 '{'，而结尾还缺 ']' 和 ')'。
真正实用的做法是：检测到不匹配时，不直接 return false，而是收集缺失的右括号（按栈逆序），再拼成建议字符串。但注意——这仅适用于“补全建议”，不能替代语法解析器。
- 补全结果依赖栈内剩余左括号顺序，必须从栈底到栈顶逆向输出（即先补最外层）
- 不要尝试插入原字符串——
std::string插入开销大，且位置判断易错；只返回建议字符串即可 - 如果输入含注释（
//或/* */），必须先剔除，否则补全逻辑会被干扰——这点在真实代码检查中几乎必踩
括号检查本身不难，难的是和实际文本处理耦合后的各种干扰项：转义、注释、Unicode、换行符。先跑通纯括号逻辑，再逐个叠加过滤条件，比一上来就写“通用补全器”靠谱得多。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
