本文详解如何避免在字符串处理中重复添加邻位字符，通过索引原地修改或邻位检测两种专业方法，精准实现“将指定字母的前后字母转为大写”功能，解决常见重复拼接导致的字符冗余问题。
本文详解如何避免在字符串处理中重复添加邻位字符，通过索引原地修改或邻位检测两种专业方法，精准实现“将指定字母的前后字母转为大写”功能，解决常见重复拼接导致的字符冗余问题。
在处理类似“将字符串中某字母（如 'u'）的前一个和后一个字母转为大写”的任务时，一个典型错误是：在遍历每个字符的过程中，既在 else 分支中无条件追加当前字符，又在匹配到目标字母时额外插入其邻位字符——导致邻位字母被重复添加两次（一次作为普通字符，一次作为邻位强化字符），最终出现 brRuSssels 这类重复现象（如 'r' 和 's' 各出现两次）。
根本原因在于原始逻辑混淆了“字符采集”与“位置标记”两个阶段：它试图边遍历、边拼接，却未规避已被处理过的邻位字符的二次写入。
✅ 推荐方案一：原地索引修改（推荐，清晰高效）
将字符串转为字符列表，遍历过程中仅对满足条件的位置（即目标字母的左右邻位）进行大写覆盖，不新增字符，彻底规避重复：
def funnycase(string, letter):
letter = letter.lower()
chars = list(string) # 可变副本，支持索引赋值
n = len(string)
for i, char in enumerate(string.lower()):
if char == letter:
# 标记左侧邻位（存在且为字母）
if i > 0 and string[i-1].isalpha():
chars[i-1] = string[i-1].upper()
# 标记右侧邻位（存在且为字母）
if i < n - 1 and string[i+1].isalpha():
chars[i+1] = string[i+1].upper()
return ''.join(chars)
# 示例验证
print(funnycase('brussels', 'u')) # 输出: bRuSsels
print(funnycase('Kabul', 'u')) # 输出: KAbul（'K' 和 'b' 大写）
print(funnycase("Saint John's", 'u')) # 输出: "SAint JoHn's"（注意空格与标点保留原样）✅ 优势：逻辑直白、时间复杂度 O(n)、无字符串拼接开销、天然避免重复。
✅ 推荐方案二：邻位驱动式判断（语义更贴近需求）
不以“找到 'u'”为中心，而是以“每个字符是否毗邻 'u'”为中心——遍历每个位置，检查其左/右是否有目标字母。这种方式更符合“邻位即大写”的业务语义：
def funnycase_by_neighbors(string, letter):
letter = letter.lower()
chars = list(string)
n = len(string)
for i in range(n):
# 若当前位置的左边或右边是目标字母，则当前字符需大写（且为字母）
is_neighbor_of_letter = (
(i > 0 and string[i-1].lower() == letter) or
(i < n - 1 and string[i+1].lower() == letter)
)
if is_neighbor_of_letter and string[i].isalpha():
chars[i] = string[i].upper()
return ''.join(chars)
# 验证效果一致
print(funnycase_by_neighbors('brussels', 'u')) # bRuSsels✅ 优势：语义自解释性强，易于扩展（如支持多邻位、忽略大小写等）；同样杜绝重复。
⚠️ 关键注意事项
- 始终区分 string[i] 与 string[i].lower()：大写操作应基于原始字符（保留原有大小写意图），而比较应统一转小写。
- 严格校验边界与字母性：使用 i > 0 / i
- 不要在循环中动态修改正在遍历的字符串或列表（除非明确设计为原地算法），原始代码的 append() 模式正是陷阱源头。
- 若需批量处理城市列表（如题目中的 capitals），可结合 filter 或推导式预筛选含目标字母的城市，再统一调用 funnycase。
✅ 总结
解决“邻位大写重复”问题的核心，在于放弃“边找边拼”的流式构建思维，转向“先定位、后标记”的索引式改造范式。两种推荐方案均通过字符列表 + 索引赋值实现原子化修改，确保每个位置至多被处理一次。实际项目中，优先选用方案一（原地修改），兼顾性能与可读性；若业务逻辑未来可能演变为“所有邻 'u' 的元音需额外高亮”，则方案二（邻位驱动）更具延展性。
