项目简介
一个公司的官网，主要用来展示公司的业务相关信息，同时提供一个订单功能，需要接入在线支付服务。
技术选型
最初由于只需要一个静态站点，所以直接使用 hugo 生成。部署在 AWS 的 S3 服务，然后通过 CloudFront 服务开放给外网访问。 后来出现了订单需求，一来想尝试前后端分离，二来想实践一下当前流行的 Web 开发技术栈，所以前端选择了 React，后端则使用用惯了的 C# 以 WebAPI 的形式提供服务，数据库则选择了免费的 PostgreSQL。
遭遇的坑
React
先跟着官方文档，利用脚手架生成了一个工程，在此基础上尝试了组件的写法，一时神清气爽。 可惜很快就自然的需要组件库、路由、i18n，四处搜索，最终选择了 antd、React Router、react-i18next。 路由很快就遇到问题，如果直接输入路由 URL，这时路由是无法生效的，最后通过重定位解决了。 antd 最开始很香，官方文档给出的示例很有用，但是涉及到一些细节问题的时候，看文档就有点摸不到头脑。后来全站使用 TypeScript，到处报错，最离谱的是居然出现了类型不兼容的问题。 当然作为 React 新手，很有可能遇到的问题都是个人水平太菜造成的。
WebAPI
RESTful API 是真的清爽，只是对于 API 的设计明显与传统 Method 式接口思路不同，算是小坑，很容易填平。 因为想部署在 Linux 服务器，所以选择了长期支持的 .NET 6，跟着官方文档进行部署，倒是一路顺利，无坑。
PostgreSQL
上来就踩了表名与字段名不区分大小写的坑，实在不想带着双引号写 SQL，于是乖乖的改为下划线式的写法。 由于业务并不复杂，整体使用上很顺畅，无坑。
Linux
安装数据库时偷懒了，直接允许外网访问了，于是在短短半天的时间里，服务器就被入侵并被安装了挖矿软件，直到看到账单才发现问题，赶紧做了 IP 限制，并清除了恶意程序，大坑。
总结
关于技术选型
果然选用自己擅长的技术可以有效保证效率与质量，毕竟该踩的坑基本都踩过了，常见的解决方案也大致有了解，用起来真的得心应手。 贸然选择不熟悉的框架必然要交学费，要做好付出代价的心理准备。 选择流行度高的框架，可以降低风险，出现问题的时候，更容易搜索到解决办法。
关于信息安全
尽管现在的云服务的默认设置已经尽可能保证了一定程度的安全性，但拦不住作死的人。 不能有侥幸心理，现在的网络攻击是全自动无人值守的，只要有漏洞，很快就会被人趁虚而入。
关于 SPA
虽然 JavaScript 如日中天，大有一统天下的姿态，但仍然有它的局限性。 作为一直使用编译语言的程序员，用起脚本语言真的是浑身难受，特别是弱类型和函数式，与以往的经验格格不入。 由于 SPA 的性质，对搜索引擎不是很友好，尽管各大引擎都针对 SPA 进行了对应，但仍然有“老顽固”自己玩自己的，所以逼得出现了“预渲染”，甚至搞出“服务器端渲染”这样逆向进化的奇景。 所以我觉得 SPA 还是适用于后台管理站点或者内网应用，外网门户还是使用传统手段开发更省心。
关于框架
其实各种框架的出现，几乎都抱着“小而美”的理念，很清爽，不油腻。 可惜一旦开发商业应用，不可避免的四处寻找“轮子”，自己拼装一套“全家桶”，而各个“轮子”尽管自身设计的都很精美，但是一起用的时候还是可能会出现“风格”不同的问题，这种时候作为被微软惯坏的程序员，就无限怀念开箱即用的体验。 有鉴于此，或许下次我会尝试投入 Angular 的怀抱。
