栈是最直接的选择，因其LIFO特性天然匹配括号嵌套关系：遇左括号push，遇右括号检查栈顶匹配性；计数器无法识别顺序错误，递归存在栈溢出风险且难中断；推荐std::stack，左括号集硬编码为"([{"。
检测括号是否匹配用什么数据结构最直接
栈是最自然的选择，因为括号的嵌套关系天然符合后进先出（LIFO）语义。遇到左括号就 push，遇到右括号就检查栈顶是否匹配，不匹配或栈为空就立刻失败。
别用计数器（比如只统计左右括号数量），它无法捕获 "[)" 或 "{[}" 这类顺序错误；也别用递归模拟栈——实时监控要求低延迟、可中断、内存可控，递归有栈溢出风险且难以中途报告位置。
- 推荐用
std::stack<char></char>，轻量、标准、无需额外依赖 - 左括号集合建议硬编码为
"([{，右括号对应映射用 <code>std::unordered_map<char char></char>：如{')', '('}, {']', '['}, {'}', '{'}, {'>', ' - 每读入一个字符就立即处理，不缓存整串——这才是“实时”的关键
如何在流式输入中报告错误位置和类型
实时监控意味着不能等字符串结束才报错。你需要在扫描过程中记录当前索引，并在不匹配时立刻返回位置信息和具体问题。
常见错误类型有三类：unmatched_right（右括号无对应左括号）、unmatched_left（扫描结束栈非空）、mismatched_pair（右括号与栈顶不配对）。每种都应附带 index 和 expected 字段。
立即学习“C++免费学习笔记（深入）”；
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 用一个
size_t pos = 0跟踪当前字符下标，每次++pos后再处理 - 遇到
')'但栈为空 → 错误类型unmatched_right，位置就是当前pos - 遇到
')'但栈顶是'['→ 错误类型mismatched_pair，expected应为'(' - 输入结束但栈里还有
'{'→ 错误类型unmatched_left，位置取栈底最后一次push的索引（需额外记录，见下条）
怎么记住每个左括号的原始位置以便报错
只存字符不够，报错时用户需要知道“第 17 个字符处缺右括号”，所以栈里不能只压 char，得压一个带位置信息的结构体。
最简方案是用 std::stack<:pair size_t>></:pair>：每 push 一个左括号，同时存下它的索引。这样当最终发现栈非空时，栈顶元素的 .second 就是最内层未闭合括号的位置，而栈底（最早 push 的）才是最外层遗漏点——但通常只需报告第一个未匹配项即可。
- 初始化栈：
std::stack<:pair size_t>> stack;</:pair> - 读到左括号
c时：stack.push({c, pos}); - 报
unmatched_left错误时，取stack.top().second作为位置，stack.top().first作为期望关闭的括号类型 - 注意：
pos是从 0 开始还是 1 开始，需统一——建议对外暴露 1-based 位置（用户更习惯），内部仍用 0-based 处理
性能和边界场景容易漏掉哪些细节
看似简单，但实际部署时几个点常被忽略：空格/换行是否跳过、Unicode 括号支持、嵌套深度限制、多字节字符干扰。
- 默认应跳过空白字符（
std::isspace(c)），否则"( )"会因中间空格导致位置偏移 - C++ 标准库不直接支持 Unicode 括号（如「『」、「」」），若需支持，得用
std::u32string+ ICU 或手动扩展映射表，普通 ASCII 场景不必过度设计 - 深层嵌套（如 10 万层）可能撑爆栈内存，可在循环中加深度计数，超过阈值（如 10000）直接返回
depth_overflow - 如果输入来自文件流或网络，注意
std::getline或istream::get()的 EOF 判定方式，避免最后一次pos未参与检查
真正难的不是算法本身，而是把“实时”二字落到实处：位置精确、错误明确、不卡顿、不假死。栈结构只是骨架，填进去的索引、映射、边界防护，才决定它能不能在线上跑稳。
