如果“小马拉车”指的是回文子串算法 Manacher，那么选择时主要看任务规模和输出需求：要在线性时间求最长回文子串，优先用 Manacher；只处理短字符串或单次查询，中心扩展更容易实现；需要保留区间状态、做动态规划类扩展时，再考虑 DP。三种方法解决的问题相近，但实现难度、时间复杂度和适用任务不同。
先看任务：求一个答案，还是处理大量区间
只要求一个字符串中的最长回文子串时，Manacher 通常是长输入下的优选。它利用已计算回文的信息，减少重复比较，时间复杂度为 O(n)，空间复杂度为 O(n)。在字符串较长、需要稳定线性性能，或题目明确要求高效处理时，这种优势最明显。
如果字符串很短，或者只是验证少量候选中心，中心扩展往往更合适。它从每个字符以及每对相邻字符向两侧比较，代码直观、额外空间少，最坏时间复杂度为 O(n²)。数据规模不大时，省去辅助数组和边界处理，通常比追求更优复杂度更实用。
动态规划也能求最长回文子串。它记录区间是否为回文，适合需要复用区间结果，或在此基础上增加其他状态判断的场景；但一般需要 O(n²) 时间和 O(n²) 空间。若只是找最长回文，DP 通常不是首选。
| 方法 | 时间与空间 | 更适合的任务 |
|---|---|---|
| Manacher | O(n) 时间，O(n) 空间 | 长字符串求最长回文，或需要每个中心的回文半径 |
| 中心扩展 | 最坏 O(n²) 时间，额外空间 O(1) | 短字符串、单次求解、优先保证实现简单 |
| 动态规划 | O(n²) 时间与空间 | 需要保存区间状态，或继续扩展区间型问题 |
Manacher 的关键：统一奇数和偶数回文
回文子串可能是奇数长度，如“aba”，也可能是偶数长度，如“abba”。直接处理时，两类回文的中心定义不同。Manacher 通常先在字符之间插入分隔符，将两种情况转成统一的中心扩展问题。例如把“abba”改写为“#a#b#b#a#”。分隔符只是辅助表示，并非压缩数据；变换后长度约为原字符串的两倍，整体复杂度仍为线性。
算法在变换后的字符串上维护当前最右侧回文的中心和右边界。新位置若落在已有回文覆盖范围内，就先利用它关于中心的镜像位置，得到一个已知的最小半径，再继续向外比较。这样不会反复从头检查同一段字符。最终比较各中心的半径，就能定位最长回文。
实现时要注意，不同资料对“半径”的定义可能不同：有的把中心字符计入，有的只统计扩展步数。因此，初始化、镜像半径和原串下标换算必须使用同一套约定。最稳妥的做法是先用“aba”“abba”“aaaa”和单字符等例子逐项验证，再处理边界。
按使用场景做选择
- 只处理短文本，想要容易读懂的代码：选中心扩展。分别尝试字符中心与相邻字符中心即可，无须构造辅助字符串。
- 输入较长，要求高效找到最长回文：选 Manacher。它把重复扩展压到线性级别，适合对时间复杂度有明确要求的任务。
- 需要保存多个区间的判断结果：考虑 DP。虽然开销较大，但区间状态便于与其他转移条件组合。
- 要输出全部回文子串：先确认输出量。即使半径能在线性时间计算，全部结果在极端情况下也可能达到 O(n²) 个，生成和存储结果的成本不能忽略。
落地时先核对字符和下标
中文文本、表情符号或组合字符会带来字符单位差异：某些编程语言按字节或 UTF-16 代码单元遍历，不一定等同于用户看到的一个字符。若题目要求按 Unicode 字符比较，应先确定输入的遍历单位，再运行算法。还要统一原串与变换串的索引映射，避免最长长度算对了、起始位置却偏移。
实际选择可以从最简单的实现开始：短输入用中心扩展；当规模、性能要求或题目约束证明二次复杂度不够时，再改用 Manacher。若后续任务需要区间状态而不只是最长长度，则按状态复用需求评估 DP。这样能让方法与问题匹配，而不是仅因算法更快就增加实现复杂度。
