先说个最实用的，嵌套作用域的问题。比如你想设计个类似Gradle脚本的DSL，允许在闭包里再套一层配置。刚开始我直接在里面定义Lambda参数，结果发现外层的方法在内层根本调不到。这时候就得用上带接收者的函数类型了。看这个例子：
这么写就能在services闭包里调用service方法了，因为Services成了闭包的接收者。这种嵌套结构让DSL读起来特别自然，就像在写专门的配置文件一样。
再来说说中缀调用这个利器。有些DSL需要表达类似英语句子的结构，比如测试框架的。用中缀符号写出来特别流畅：
不过中缀不能随便用，它要求左边是接收者实例，右边是单个参数。在需要表达连续操作时特别有用，但要注意别滥用，否则会影响可读性。
默认参数和命名参数在DSL里也是个好东西。比如配置HTTP请求时，很多参数都有合理默认值：
这样用户只需要配置关心的参数就行，其他都用默认值，代码看起来干净多了。
操作符重载能让DSL更简洁。比如定义个操作符表示范围：
不过操作符重载要克制，只有语义明确时才用，不然别人看代码还得猜这操作符什么意思就不好了。
最后说说注解。DSL嵌套深了以后，可能会不小心从内层闭包访问到外层的方法，造成歧义。用这个注解就能限制作用域：
这样在内层闭包里就不能直接调用外层方法了，编译器会报错，强迫你写出更清晰的代码。
实际开发DSL时，我觉得最重要的是保持一致性。整个DSL的风格、命名习惯要统一，让用户能举一反三。还有错误提示要友好，毕竟DSL最后是给别人用的，编译出错时能明确指出哪里配置不对，能省很多调试时间。
好的DSL应该是自解释的，用户不看文档也能猜出大概用法。这需要在设计时多站在使用者角度思考，反复打磨API。每次迭代完找没接触过的同事试试，看他们能不能直观地上手，这是检验DSL设计好坏的好方法。