有一群很棒的同事一起打理喜欢的事业应该每天都很有趣吧。

人漂亮，设计漂亮，技术也漂亮。膝盖给你就是。

@jijifly v 站上找不到你的联系方式。可以发我邮件你的联系方式吗？我有个想法不知道你感兴趣不。leeys.top@gmail.com 或者是我的 qq 邮箱。你应该找得到的。

@jijifly 我认认真真读了 3 遍你的留言。先道一声谢谢。事实上我对 demo4 不是三分钟的热度，反而我有我的某些认真的思考。其实代领快递我很早就思考过了，首先需要实名认证，谁都不想花一两块钱最后东西被拿走，我通过某种灰色渠道实名这块应该不成为问题，其次学校已经有人做这一块市场，其次快递我们常常会托室友或者同学顺路代拿，所以代拿快递这一块一味鲁莽的切入只能说吃力不讨好。还有大家说的代 XX 其实我都不太中意，在今年我已经想不出有什么代 X 能做得比校内实体或者已经在做的人做得更好。

层主你的话我很多都认同。但一开始打着免费后续做广告对于目前的我来说不太喜欢这种方式，我想尝试一种新风格，掘金的成功从某种程度上来说它像是一开始就蓄意打造一种高端的氛围并刻意筛选第一批非常优质的黄金种子用户，虽然我没有上掘金的习惯（可能觉得上面充斥太多的干货反而会让我有种急功近利的态度），但掘金的在各大技术论坛的广告其实我都非常能接受，令我印象最深刻的是在百度搜索上竟然为其一篇正则表达式文章打了广告。所以我想尝试这种一开始首先筛选一批三观大致相同的黄金种子用户，包括老师或者同学，然后再由这些人去做二次发散。固然想法是美好的，但这第一批种子用户的口味势必很难伺候，曾经我也经常因为写不出高性能的代码或者做一些高质量的设计而感到力不从心。我很害怕广科小狗会变成无数 engineer 风格产品中的一款。

第 7 点我有一点不同的看法，我问过一些人，几乎没有人能明确清晰地说清楚他们需要什么，侧面其实也证明真理掌握在少数人这一观点，学校的同学目前给我感觉的是从众的人还是占很大比例。这些人他们可能就是说不出自己需要什么，只有把东西盛在一个盘子里一吃一比较才知道，哦这个比较好吃。

最后感谢你让我思考得更多，我始终还是执意尝试以收费服务的形式打造广科小狗，这很可能是我大学生涯中最后最后一个 demo 了。

这几天我已经在重构 demo4 了（昨天刚完成之前遗留下来的中文全文索引问题）。不过现在安卓和 UI 还是找不到很棒的合伙人。谢谢这几天各位 v 友的陪伴。透过你们字里行间我知道你们才是真正的年轻过、付出过和收获过。

最后谢谢 @jijifly，从你的昵称和你的留言我能感觉到你其实是一个非常有趣的人。

代点名、代作业、代考、代。。。。 我天哪，难道你们就没有不太灰色的东西吗

@wintercoder http://ids.gdit.edu.cn/amserver/UI/Login? 有 nginx 的服务器。说明开启，不过好像没有什么页面

@wintercoder 非常感谢你的支持。我们学校就是江苏汇文。图书馆功能其实我已经做出来了。难点还是在登录的图片验证，不过图片很整齐，一切一对比，验证码正确率 100%，github start 你了。

@CEBBCAT 在于这种分享会增加 app 的曝光量，同时一个人的微信的好有数量是非常有限的，大多都是认识的人，而认识的人捡到他的东西应该会立即联系。所以 app 的失物招领分栏更像是一个优雅的信息曝光平台，同时丢失人分享增加曝光量，大致应该是这样吧。

@markyangd 哈哈哈。灰色地带。

@CEBBCAT 谢谢。我希望这段时间犹豫少一点，执行力多一些。图书馆有微信号，但体验非常糟糕。丢东西时 app 需要有分享功能，最好能分享到朋友圈，（不过微信我还没接触过，未来要下点功夫），做一些病毒式的传播。还有社交这一块我是非常慎重，我本身就是一个不会且不爱社交的程序员。如果这个 app 有合伙人的话，我更希望也擅长社交或者是一个很有趣的人。

@keinx 建设性的评论！看得出来你曾经年轻过。愈发激励我想尝试一番，相比之下我还没"年轻过"。用户体验我尽全力做好。确实这一块用户量也是一个严峻的问题。我曾经跟实物招领社团问合作的意向，他们说有，但当时我还没有收费的打算，只是说这是一个校园公益 app。收费服务这一块确实非常有难度

@em70 这些。。。其实我们校内的实体店做得已经很好，现在的校园不比两三年前了。we are coder，we need something new.

@gogobody cool，同大二。你是写安卓的吗？

@senghoo 嗷嗷。这样呀。可能我的固执吧，还是不打算跟学校合作。

@senghoo 大一时候问过教务处，api 没希望。我的数据来源都只能通过灰色渠道，实名认证也只能靠灰色渠道。不希望做广告，我真心想尝试付费服务。谢谢你的建议。

感谢大家的提醒，现在问题终于发现了。我在这里分享给大家。
首先按照 oauth2 的流程，在经过用户同意授权后我根据新浪传递的 code 值向新浪获取用户信息，此时会返回（长达 2000 字符）信息，我从中提取去用户名，uid，简介三个字段，另外开发时对于新浪返回这么多的信息我也没在意，想着以后可能要用到，干脆就新建了 3000 长度的字段存储这段 json。在 @ChenPeiPei 的提醒下，查过 Tomcat 日志后才发现这些注册失败的用户他们的第一条微博里都有 emoji 表情，emoji 采用 4 字节存储，而服务器的 MySQL 使用 utf8，只支持 3 字节。导致数据库插入失败抛出异常。https://www.v2ex.com/t/137724 V2EX 创始人有关于 emoji 存储的讨论，我在本地尝试改用 utf8mb4 时能够解决问题，不过对于 jpa 的使用者来说比较糟糕，首先 innodb 引擎的索引默认最多 767 字节，utf8 编码下索引最多支持 255 （ 255*3=765 ）字符，而 utf8mb4 编码下索引最多支持 191 个字符，当然这只是默认情况下，你能够自行修改，用过 jpa 的人都知道支持使用注解创建索引，但偏偏不能自定义索引的长度。基于以上考虑我没有选择改用 utf8mb4 编码，我 emoji-java 库来去除 emoji 表情。用法是 EmojiParser.removeAllEmojis('包含 emoji 的字符串')

@Sixzeroo addEventListener("keydown", function(e) {console.log(e.keyCode)}) 在控制台输入，然后在页面按下 AD 看看 keyCode 是不是 65 和 68 ？ 难道你们那边是 97 和 100 ？