用字典构建多叉树时不能直接嵌套赋值tree[node] = tree[child]，因为Python字典值是引用而非深拷贝，会导致父子节点共享同一子树对象，修改一处影响其他分支；正确做法是用{}或dict()新建子节点，或用setdefault确保键存在且值为字典。
用字典构建多叉树时，为什么不能直接嵌套赋值 tree[node] = tree[child]
因为 Python 字典的值是引用，不是深拷贝。如果用 tree[child]（一个 dict）直接赋给 tree[node]，会导致父子节点共享同一子树对象，后续修改任意一处都会意外影响其他分支。常见现象是：添加部门 A 的下属后，部门 B 的结构也变了。
正确做法是始终用新字典表示子节点，或显式复制：
- 初始化子节点用
{}或dict()，而非复用已有变量 - 若需复用结构（如模板部门），用
copy.deepcopy()，但注意性能开销；普通场景直接重建更安全 - 避免在循环中反复对同一个 key 赋值 dict，应先清空再填充，或用
setdefault(node, {})确保键存在且值为 dict
从扁平员工列表生成组织架构树，关键在找根节点和建父子映射
输入通常是类似 [{"id": "003", "name": "张三", "manager_id": "001"}] 的列表。核心问题不是“怎么存”，而是“怎么连”。根节点往往满足 manager_id 为空、为 null、或不在任何 id 中——不能硬编码为 "000" 或 "CEO"。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 先遍历一遍数据，收集全部
id和全部manager_id（过滤掉空值），根节点 =set(all_ids) - set(all_manager_ids) - 用
defaultdict(dict)或普通 dict 配合setdefault构建映射：tree.setdefault(manager_id, {})["children"] = tree.setdefault(manager_id, {}).get("children", []) + [child_node] - 不要边遍历边递归构造，容易因顺序错乱导致 KeyError；先建好所有节点字典，再统一挂载子节点
json.dumps(tree, indent=2) 输出乱序？是因为字典默认无序，但 Python 3.7+ 已保持插入顺序
如果你看到输出里 “children” 总在最后、“name” 在中间，不是 bug，是字典键顺序取决于你插入的先后。组织架构常需按职级或字母排序展示，但 json.dumps 不自动排序。
解决方式取决于用途：
- 仅调试查看：用
json.dumps(tree, indent=2, sort_keys=True)强制按键名排序 - 前端渲染需要稳定顺序：构造节点时固定键顺序，例如统一用
{"id": ..., "name": ..., "children": [...]}，而不是动态拼键 - 导出为标准格式（如 orgchart.js）：提前把
children提取出来单独排序（按 name 或 level），再合并回节点，别依赖 dict 键序
查询某个员工的所有上级，为什么不用递归查字典而要预建反向映射
从叶子往根查时，如果每次都在字典里一层层 for node in tree.values() 找 manager_id 匹配，时间复杂度是 O(N²)，1000 人就可能卡顿。真实组织架构查询高频且要求快。
更高效的做法是一次性建好反向索引：
- 遍历时同步维护一个
parent_map: Dict[str, str]，key 是员工id，value 是其manager_id - 查上级链路时，只需 while 循环查
parent_map.get(emp_id)，O(1) 单次查找，整条链 O(D)，D 是层级深度 - 如果还要支持“查某人下属总数”，可额外缓存
subtree_size字段，在建树后做一次后序遍历填充，避免运行时重复统计
真正难的不是“怎么表示树”，而是“哪些关系必须预计算、哪些可以懒加载”。组织架构一旦超过百人，字段缺失、循环汇报、虚拟岗位这些业务细节，比字典嵌套语法重要得多。
