验证码作用更多是防止随意的机器，目的是给机器造成麻烦，但是我也见过很多项目的验证码是没有任何效果的，这里说的无效验证码包括图形验证码和短信验证码。
为什么说是无效的，不是因为验证码的图形做的太简单很容易图形识别，这种不算无效的。
下面举例子无效的验证码，
图形验证码，点击获取验证码变图形，点击后，服务端把真正的图形验证码对应的文字返回给前端（web或者安卓或者ios），然后你在输入框输入验证码，前端（web或者安卓或者ios）在本地判断，web的就是指js判断了，（同理安卓 ios的也是判断输入框的值等不等于某个值），如果你填写的值与服务端返回的验证码不相等，在点击提交时候，前端（web或者安卓或者ios）提示你的验证码输入有误，进而不请求提交信息的接口。这种在普通测试人员里面看起来似乎没毛病，普通测试人员会用等价类，填不正确和正确的验证码进行测试，当然发现不了什么大问题。但是我们换个思路，直接请求提交信息的接口，可以看到验证码并没有同其他参数一起post到服务端，那这就很好办了，在web ios 安卓里面操作，你不填写正确的验证码，他会提示你验证码错误然后不请求提交信息的接口，但你也可以不用这些前端，用requests直接请求接口，那么这就是要说的无效验证码了。
短信验证码也有无效的情况，原理和这个差不多，也是前端（包括web ios 安卓）请求了服务端短信验证码接口，然后服务端把验证码返回给前端了，并且服务端去用手机号码和验证码调用短信平台，前端在你提交信息时候先判断你填写的验证码是不是正确的，如果正确了再请求提交信息的接口。这种也可以直接用requests解决，当然如果你不会requests，你也可以用抓包工具如f12 fiddler抓包服务端返回给前端（包括web ios 安卓）的验证码，这样即使你没有别人的手机卡收不到短信，你也可以轻松获得任何手机号码的验证码，然后把抓包得到的验证码填在输入框，提交信息时候就不会提示你验证码有误了。试想这种地方如果是在短信找回密码的地方，会有多么严重的后果。
短信验证码接口做的太简单的不行，所有短信验证码的地方前面应该加入一个图形验证码。万一有人恶意请求接口，短信平台的费用刷刷的没了，这不是危言耸听，是我自己见过并且实践过的，一个很少人用的项目，不到一天2000元短信费用居然耗尽了。
所以，各位要注意了，很多没很多经验的开发团队，过分的依赖前端处理信息，造出这种项目是很不好的，这种验证码的目的已经是倒行逆施了，验证码的目的变成了防人不防机器了。
本来是要举实际例子，把真实的地址贴出来，但考虑一下这样还是不好。