翻阅了不少教程，最终在以下两个教程中一步步找到了正确的发币道路。请注意，两份教程均非常详细，但均不涉及代码编写以及拓展，需要提高的小伙伴不必继续看了。
主要参考教程有二
1、（！注意，此教程有坑，可能为版本原因）https://ethfans.org/topics/118
2、此教程现版本看已经踩平所有坑。https://mp.weixin.qq.com/s?__biz=MzI3NzQ2MjU4NA==&mid=2247483998&idx=1&sn=71602644a8f66fdb3b3142f0fae08b3c&chksm=eb64a909dc13201fb271338fab012ecea14a888bf81ce2bc7a0ab527eaa31b39e3391f1243c1&scene=21#wechat_redirect
首先在此感谢两位前辈的指导和帮助。
下面开始说一些自己的话。
发币具体步骤上面教程中已经说的足够详细。
这里主要说下遇到的一些坑:
一、代码变更
这里问题主要是在第一个教程中的坑，已经有成功的教程再说它的意义在于，一来此教程使用的是ETH官方钱包进行发币操作，而另一份并不是；二来可以促进代码理解，颇有益处。
1、报错No visibility specified. Defaulting to "public"
This happens when you are not specifying visibility of the function.
I suggest to read Solidity Documentation to understand Function Types and Visibility and Getters.
There are currently 4 function types:
- public - can be used both as an internal and as an external function.
- internal - can only be called inside the current contract.
- external - can be called from other contracts and via transactions.
- private - are only visible for the contract they are defined in and not in derived contracts.
以上是https://ethereum.stackexchange.com某位前辈的解答，其实这个错误意义上是一个警告，就是告诉你函数类型没有指定，如下方式指定即可
function XXX() public {}
2、报错"throw" is deprecated in favour of "revert()", "require()" and "assert()".
throw已经被废弃了，改用require等函数即可，如下用法：
require(balanceOf[msg.sender] < _value);
3、这个坑就有点恶心了
supply 发行总量要算上精度，比如发行总量是10亿，正常逻辑是1个1，然后后面10个0，但实际上要填1个1，然后后面18个0，这样最终的才行总量才是10亿，有点坑，推测为版本更替所致，但并没有找到印证。
第二份教程使用的为remix发币，并无此问题
4、这里是一个未解决的坑
现象为，在ETH官方钱包发币成功，也拥有了正常的币数。但在使用合约转给其他地址token的时候无法成功。此时我接触到了第二版教程，成功发布测试币种，可以实现合约发送（transfer函数）（借助网站界面，尚未研究调用合约发送），账户之间发送（transferfrom函数）等功能。至此，无法使用合约发送代币的问题遗留，尚未解决。
至此本文踩坑记录结束，虽然还有一只脚还在坑里，emmm，由于此问题暂时优先级并不高，遂滞后研究。下面说一些关于合约接受ETH，程序调用ETH合约的延伸。
此延伸起于发现第一份教程中发行成功的币无法发送代币时，推测原因为智能合约地址中没有ETH。且尝试无法使用ETH钱包转入。
-
第一步推测：无法使用发币账号转入（推测原因是找到类似一些言论）
遂使用MyEtherWallet.com新建了一个测试账号，试图发送ETH给智能合约地址，但交易一直失败，提示reverted。 -
第二步推测：代码缺失
尝试对比了第二个教程中的代码和第一个教程中的代码，未发现相应功能代码，遂推测应该是合约接受ETH也可能需要函数支持，借此道路找到了如下文章：
https://www.jianshu.com/p/9638b121885e
https://www.jianshu.com/p/54fca7b0fb72
https://blog.csdn.net/ddffr/article/details/76549320
此中发现了一些payable函数的影子，其本质可能为一个奖励机制。
至此也是有了一些结论，验证payable函数（涉及禁止的ICO问题，所以可能并不会使用）、研究代码调用合约发送代币都需要继续研究，权先记录，后待更新。
