该项目“golang debugger”，是一款面向go语言的调试器，现在业界已经有针对go语言的调试器了，如gdb、dlv等等，那么为什么还要从头再开发一款调试器呢？
建立项目的初衷并不是只为了开发一款调试器，而是希望从调试器为切入点，将作者多年以来掌握的知识进行融会贯通，这里的内容涉及go语言本身（类型系统、协程调度）、编译器与调试器的协作（DWARF）、操作系统内核（虚拟内存、任务调度、系统调用、指令patch）以及处理器相关指令等诸多内容。
简言之，就是希望能从开发一个go语言调试器作为入口切入，帮助初学者快速上手go语言开发，也在循序渐进、拔高过程中慢慢体会操作系统、编译器、调试器、处理器之间的协作过程、加深对计算机系统全局的认识。由于本人水平有限，不可能完全从0开始自研一款调试器，特别是针对go这样一门快速演进中的语言，所以选择了参考开源社区中某些已有的调试器实现gdb、delve作为参考，结合相关规范、标准慢慢钻研的方式。
希望该项目完结之时，能将其沉淀为知识分享，如果能以书籍的方式最终出版，那再好不过了，也算是我磨练心性、自我救赎的一种方式，也希望能帮助到对此感兴趣、未曾涉足的同僚。
请邮件联系 hit.zhangjie@gmail.com，标题中请注明来意golang debugger交流。
我们的基本协作方式基于github展开：
- 提出ISSUE
- 提ISSUE之前，请务必先搜索是否已经存在近似描述的ISSUE，如果已经存在可以在ISSUE下补充描述，请避免重复提相同ISSUE的问题；
- 新建ISSUE的时候，请根据问题类型选择ISSUE模板，如新特性、Bug、优化建议等，并根据模板内容填写信息，方便我们高效地进行协作；
- 解决ISSUE
- 首先需要Fork主仓库到自己的仓库中，并定期保持代码库更新；
- 当准备解决一个ISSUE前请务必确认是否ISSUE是否被开发者认领，考虑到大家可能提出不同的解决方案，方案探讨可以在同一个ISSUE下进行，避免重复处理同一个问题；
- 在决定将内容推送到本仓库时，请先拉取本仓库代码进行合并，并处理好冲突，同时确保相关文档与代码保持同步；
- 然后再将分支PR到主仓库的master分支，其中PR需要包含以下基本信息：
- 标题：本次PR的目的（做了什么工作，修复了什么问题）；
- 内容：如果必要的话，请给出对修复问题的描述，力求简短清晰；
- 项目维护人员在PR评论区进行评论，如果发现PR中有什么问题，请直接指出并尽量给出修正的方式，或者也可以直接进行修改；
- 提出该PR的人根据评论修正内容，然后将修改后的内容Merge到master分支中；
- 项目维护人员审核通过，合并PR到主仓库中；
- 每次Pull Request应只解决一个问题，这样方便进行修改；
- 每次Pull Request应确保已经同步过主仓库代码、解决冲突，并自己在本地测试通过；
- 根据贡献者的活跃程度、对框架贡献熟悉程度，我们会筛选一部分开发者加入项目维护人员列表中来；
希望热爱开源并对debugger、dwarf、golang等相关内容感兴趣的同学加入进来，共同参与该项目的建设，让“开发”变得更简单美好，让知识钻研、分享变得更加纯粹。