编译器或解释器的参数如果能影响语法的含义或支持，就算配置。用心智空间换打字速度人都是很懒的，能既省时间又省精力干嘛要重复做那些麻烦的事我想到了lavavel，你倒是举个例子啊～～作为一个可悲的java开发者，我说一下感性的东西。
多组件配合的时候，你可以去配置，100个配置点你就有写100遍，因为你不可能知道这些配置点默认值是什么，是否必填项。
那么，约定就好像java的getter和setter，name属性，它的setter必然是setname,getter必然是getname，我不需要去配置中指定，用反射直接可以拿到setname和getname。
这是一种设计理念，一个团队中约定条件1 2 3，比如，dao的底层sql查询用add_表示增、del_开头表示删除，那么配置事务时候就直接add_* 指定一个策略就行了，这是约定。减少你出错的可能性，这是工程层面的东西，那么扩展到一种语言，就好像java的getter和setter，也算一种约定，但是为了语言的灵活性，这样的约定会比较少，不像框架中约定使用的这么随意。就好像和熟人合作优于陌生人，但现实是残酷的约定重于配置会造成熟的人上手很快，不熟的人学习成本上升。
约定重于配置会导致扩展性下降，为了弥补配置的不足会产生很重的实现，最终又体现在学习成本的增加上。
约定重于配置能够让熟手在熟悉的领域快速开发，长远来看不一定是好事。约定大于配置，只要记住约定的，就少写了配置文件没见过哪个语言？go语言的函数首字母大写表示public、小写表示private算不算？