这是我参与「第五届青训营」伴学笔记创作活动的第 13 天
今天复盘一下项目开发中遇到的问题，及解决方案
本人主要负责评论模块和点赞模块业务的实现
总来地说就是CRUD，其实没有说明太大难度，但是在故障排查和代码优化中，遇到一些问题，这里来总结一下
故障排查
在本项目中主要遇到的问题就是panic，各种panic
有的是调用一些接口或函数，返回了error，但是没有捕获处理，这种情况下会直接panic
当Go语言程序运行时出现panic时，可以按照以下步骤进行排查：
- 查看panic的错误信息：当程序出现panic时，Go语言会自动打印出错误信息，并且会在错误信息中显示panic的原因。因此，首先应该查看错误信息，了解panic的原因。
- 使用defer语句恢复程序状态：当程序出现panic时，可以使用defer语句进行状态恢复，以保证程序能够正常运行。例如，可以使用defer语句来关闭打开的文件、释放占用的资源等等。
- 使用GDB进行调试：如果错误信息无法说明panic的原因，可以使用GDB进行调试。首先，需要在程序中设置断点，然后使用GDB进行调试。在调试过程中，可以查看程序的状态、变量的值、堆栈的信息等等，以确定panic的原因。
- 使用Go语言的调试工具进行调试：Go语言提供了一些调试工具，例如pprof、trace等等，可以用于查看程序的状态、堆栈的信息等等，以确定panic的原因。
- 使用日志记录程序状态：可以使用日志记录程序的状态，以便在程序出现panic时查看程序的状态。可以在程序中添加日志记录代码，记录程序的状态信息，例如变量的值、函数的调用等等，以便在出现panic时查看程序的状态。
其次遇到的问题困扰了时间最久的，在进行RPC调用时，没有对一些RPC服务进行初始化，也可以简单理解为，定义了变量，没有赋值，这样就造成了panic。
其次，当本RPC模块调用了其他RPC模块时，没有调用的其他RPC模块进行发现，也是故障造成的原因
这种错误，如果不是从0开始构建项目，逐步完善，通过打断点，调试是无法解决的。
代码优化
优化数据库查询次数
在对数据库进行查询时，如果不确定返回结果的多少，可以采用slice，初始化容量为0（因为可能没有数据）而不是先在数据库中查询数量（count函数）再创建对应大小的数组
这样会增加一次数据库的查询，请求会将时间浪费在一次多余的查询上，导致性能下降。
进行合理封装
将一些经常重复出现的代码进行合理的抽取出来，封装，可以减少代码冗余，让代码更加简洁。
另外，微服务原则上各个数据库、服务之间是相互隔离的，不应该共用一个数据库，所以不能采用连接查询的方式来获取数据，而是应该通过模块间调用接口来实现
减少不必要的内存使用
减少不必要的内存占用
在数据库查询之前，先不要定义响应信息，毕竟还不知道数据能否查询成功。
如果不成功，那么这个过程就要多使用一些内存空间。
当请求量激增时，很小的额外内存占用必然会导致服务性能下降
