Laravel模型必须定义reciprocal relationships还是仅推荐使用？

不存在框架层面强制要求必须定义双向关联的隐式规则，这类关联本质是按需取用的便捷能力，不是必须遵守的强制开发规范。

• 如果你的业务逻辑里完全不会用到反向查询的场景，比如你只需要通过$item->type获取条目所属类型，永远不会通过类型查询下属的所有条目，完全可以不在Type模型中定义items()关联方法。这种情况下已定义的正向关联可以正常运行，不会触发任何框架报错，也不会影响Eloquent的核心功能。
• 但有几类场景你可能没有显式写反向查询代码，却会隐式依赖反向关联的定义，缺了就会出问题：
  • 用到关联的写入、绑定、级联操作时：比如调用$type->items()->create()批量创建关联条目、用associate()/dissociate()绑定从属关系、开启关联cascadeOnDelete级联删除、在子模型中配置$touches属性自动更新父模型时间戳时，框架会主动调用对应关联方法执行逻辑，没定义反向关联会直接报错或者功能静默失效。举个最常见的例子：你在Item模型的type关联上开了自动touch，item更新时框架会自动找Item对应的Type模型更新时间，这时候如果关联定义缺失，touch逻辑根本不会执行。
  • 用到预加载嵌套、关联聚合查询时：比如你写Type::with('items')预加载类型下的条目、或者用withCount('items')统计条目数量，这类查询本身就是基于反向关联实现的，没定义关联自然跑不通。
  • 用到Laravel生态配套工具时：比如后台面板、模型策略权限校验、嵌套路由隐式绑定这类场景，很多工具会按照Eloquent的默认约定查找对应关联做权限判断、路由解析，如果没定义反向关联可能出现莫名其妙的404、权限校验不通过问题，这类属于生态的隐式约定，不是框架核心的强制要求。

不用在开发初期为了"符合最佳实践"硬写全所有可能的双向关联，等实际用到对应查询、或者碰到上述隐式依赖场景时再补定义完全来得及。唯一需要额外注意的是：只要你在关联上配置了自动触发的逻辑（比如级联、touch、模型事件监听），就一定要保证对应方向的关联方法存在，避免出现没报错但功能没生效的隐性bug。

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