参考:

1. MQTT Essentials Part 5: MQTT Topics & Best Practices
2. 5 Best Practices for Creating Topic Structure - Xively Blog

结合参考和自己的实践:

1. 不要在最前面加 /
   比如: /home/device/light, 等于在最前面有一个空字符串层级，这完全没有必要而且增加了broker之类的处理, home/device/light 才是合理的。
2. 就使用英文+数字字符，不要使用空格、特殊字符
   这些都会增加处理的复杂性，有时候还会有兼容性问题
3. 将设备ID或识别码包含在topic中
   多方面原因：便于订阅特定设备、便于后续的过滤、便于权限控制
4. 不要在运行中创建 topic
   这个好理解，交流还是有预期比较好。在规模较大的系统中，随意的创建 topic 会导致维护困难、处理复杂度增加，最主要的肯定非常容易导致遗漏和未知行为。
5. 命名简单明确
   太长了看太累，看不懂会困惑，太累或困惑都容易出错； topic 应该尽可能细致，能详细定位到不同的设备和消息

PS: 据说写代码最难的是命名，对我等非英语母语的更如此吧。

6. 命令字保持一致，并放在最后
   MQTT不像HTTP有多个方法，RESTful因此将CRUD映射为HTTP方法。当然MQTT通常只有一个控制下发命令字，状态和属性是主动上报的。MQTT可以将方法放在topic最后，这样也便于统一的下发处理， 比如: home/bedroom/bedlight/rgb/set

总结

虽然MQTT和HTTP在实践中有非常大的差异，比如HTTP是请求->响应方式，其有丰富复杂的头部，有明确定义的状态码等。但是 topic 设计和 RESTful URI 设计很多是相通的思想，比如明确的资源路径、无状态、简洁明确、一致的命令字(REST通过方法表达)等。

啰嗦一句, 很多东西的道理都是相通的，个人对很多东西是否合理的基本判断是: 
1. 看起来是否很明白
2. 用起来是否很顺利