spice网表是弱结构化文本，需逐行解析并保留大小写；用正则粗分块、小心续行与引号；子电路递归须防栈溢出；节点/元件名原样存储，空节点按仿真器约定映射。
SPICE网表本质是文本，别用XML思路去解析
SPICE网表（如 .cir、.net）不是结构化格式，没有统一Schema，不同仿真器（LTspice、NGSPICE、PSpice）对注释、缩进、续行符（+）、大小写敏感性的处理差异极大。硬套JSON/XML解析器会立刻卡在第一行——比如 V1 in 0 DC 5 里 V1 是元件名还是类型？in 是节点名还是变量？得靠上下文判断。
实操建议：
- 用
StreamReader逐行读取，跳过空行和以*或.开头的注释/控制语句（但注意.include必须递归加载） - 对每行先做
Trim()再按空白符分割，但小心引号包裹的值（如AC "1.2kΩ"），简单Split(' ')会切错 - 遇到行尾的
+，要合并下一行内容（LTspice 允许+在行首或行尾，NGSPICE 只认行尾） - 节点名允许数字开头（
12、0是合法地节点），但 C# 变量不能以数字命名——别直接当 identifier 用
用正则预处理比手写状态机更稳
手动维护「当前在解析元件/模型/子电路」的状态容易漏边角情况（比如嵌套 .subckt 里又含 .model）。不如用正则先做粗粒度切分，再逐块处理。
实操建议：
- 用
Regex.Split(text, @"^\.(end|subckt|model|include)", RegexOptions.Multiline | RegexOptions.IgnoreCase)拆出主干块 - 对元件行（如
R1 n1 n2 1k），用^([a-zA-Z]\w*)\s+(.+)$提取标识符和参数部分，再对参数二次分割 - 避开贪婪匹配：
"([^"]*)"比".*?"更可靠抓引号内内容 - 别用
RegexOptions.Compiled—— 网表通常不大，编译开销反而拖慢首次解析
节点名和元件名的大小写必须原样保留
SPICE 规范里，节点名区分大小写（VCC ≠ vcc），而 LTspice 默认不区分，NGSPICE 区分。如果你把所有节点转成小写再建图，仿真结果可能完全错位——尤其在混合使用多个网表来源时。
实操建议：
- 用
Dictionary<string node></string>存节点，Key 用原始字符串（不调ToLowerCase()） - 元件实例名（
R1、C2）同样保留原样；但类型前缀（R、C）可统一转大写用于后续 dispatch - 遇到
.param VDD=3.3这类定义，值要进预处理器，不能当普通节点名塞进拓扑结构 - 空节点（
0、gnd、GND）需按实际仿真器约定映射为同一参考点，不能只看字面是否相等
子电路（.subckt）递归解析时栈深度要设防
恶意构造的网表可以写几十层嵌套 .subckt，C# 默认栈不够用，StackOverflowException 直接崩溃。而且子电路端口顺序和内部节点名作用域是隔离的，平铺到全局会冲突。
实操建议：
- 用显式
Stack<subcircuitcontext></subcircuitcontext>替代递归调用，每进一层检查stack.Count > 100并报错 - 子电路实例化时（如
X1 a b c myamp），把端口映射关系存进局部上下文：["a" → "in", "b" → "out"]，而非重命名内部节点 -
.subckt块内的.model定义只在该子电路内有效，需挂载到对应上下文，不能丢进全局模型池 - 避免在解析中实时构建矩阵——先收全拓扑，再统一生成导纳矩阵；否则子电路展开时机错乱会导致节点编号重复
真正难的不是读出字段，而是搞清哪段文本属于哪个作用域、哪个仿真器变体、哪个抽象层级。一个没处理好的续行符或大小写，就能让整个网表连不上地。
