列表转字典时用{}和dict()的区别？为何dict()带/不带方括号均生效

问题1：为什么有无方括号对dict()传参效果无差异 #

dict() 构造函数本身支持传入任意可迭代对象，只要迭代返回的每一个元素都是包含2个元素的子可迭代对象，就会自动把第一个子元素作为键、第二个作为值生成字典：

• 你写的CASE1没有加方括号，属于生成器表达式：本身是可迭代对象，会逐次产出每次input().split()得到的二元列表，不会提前把所有结果存入内存。
• CASE2加了方括号，属于列表推导式：会先把所有input().split()的结果存入一个列表再传给dict()，属于一次性加载所有数据的可迭代对象。

因为两者都是符合要求的可迭代对象，数据量小的情况下运行效果完全一致，只有处理超大量数据时，生成器表达式的内存占用会明显更低。

问题2：{}和dict()转字典的核心差异 #

你最初的报错本质是语法误用：{input().split() for _ in range(3)} 是集合推导式的语法，不是字典推导式——字典推导式要求必须显式声明键:值的结构，格式为{k:v for ...}，集合推导式只需要单个元素，而集合要求所有元素可哈希，split返回的列表不可哈希，才会触发unhashable type报错。

两者的核心差异如下：

1. 语法要求不同
   • 字典推导式必须显式定义键值映射逻辑，适合需要对键/值做额外处理的场景，比如你需要把手机号转为整数时，直接写{name: int(phone) for name,phone in (input().split() for _ in range(3))}就可以实现，逻辑更直观。
   • dict()不需要显式写键值映射，只要传入的可迭代对象的每个元素都是二元结构就可以自动解析，适合输入已经是标准二元可迭代序列的场景，写法更简洁。
2. 底层执行逻辑差异极小
   只要处理逻辑一致，两者生成的字典完全相同，重复键的覆盖规则也一致（后出现的键覆盖先出现的），性能差异可以忽略不计，只需要根据场景选择可读性更好的写法即可。

内容的提问来源于stack exchange，提问作者Taniya Patel