@rookie2luochao #3 ，事实上大部分的工作都是很无趣的……一直有挑战，这样的工作内容是有问题的。

PC 和移动端的交互逻辑是不一样的。所以不可能用同一套来实现，除非拆开成 3 个选择器来实现。
但是 PC 端一般都是下拉选择，而移动端会考虑使用滑动 Picker 的形式。

---
就算是 3 个 Select ，业务逻辑也是一样的，传入过滤好的 optionList 。过滤的规则就是当前的 parentKey === 上一级选择的 key ，上级切换的时候触发一次就好了，同时也可以置空后续的选择框。
然后 CV 一套到移动端，把组件的 refs 改一下就行了。

创建完了之后是啥就用啥。

Github 创建时勾选了创建 README.md 的话，默认分支是 main 。那么就用 main
内部的 GItlab 创建好像不会自动创建主分支，所以 git init 时创建默认主分支就还是叫 master ，那就继续用 master 。

----

好多人会把 main 拼写成 mian ，master 好歹不容易拼写错……

如果有频繁开关需求的话，翻过来放才是正解 /dog

Win10 + VSC 终端 + 自带中文输入法

没能复现你的问题。感觉可能是你引用的帖子里面说的输入法的问题？但是也不应该啊……

https://imgur.com/1Mwy8TL

人会有分两种不同偏好的学习方式： 理论先行 和 实践先行。以此衍生出来 [4 个象限]( https://docs.divio.com/documentation-system/)
基于不同的偏好文档的好坏评价也是不一样的。


-----

不管是技术笔记，还是官方文档，都不适合照搬照抄。很多文章发布超过 300 天的，剩余的价值只是他的思想了。

我一般都是直接看最新的文档，而不是看别人的分享。
只有来来回回看不明白、理解不了的部分，才会单独检索查看别人的分享，去针对性的加深学习。

但是很多库和工具，也许只是实现了作者的某一个想法或者辅助他实现某一个功能。
并不一定会觉得说会有很多人去使用，所以并不一定会有很完善的文档。不可避免的会有很多困扰。

至于中文内容的落后是没办法的。英语作为世界语言，绝大多数的文档和资料都会优先考虑英语作为主要语言。其他语言作为原文档的翻译肯定会落后一段时间。
各种库对于中文的支持也是，很多开发者并不会考虑不同语言的输出。才会有各种分享说不要用中文目录之类的。
同样的很多的库也都没有很好的支持 [RTL]( https://developer.mozilla.org/zh-CN/docs/Glossary/RTL)

独立产品最困难的在于如何推广和运营，然后才是点子和实现。

@WallenHan #97 ，没有。多次尝试基本上都是失败告终的，所以没有什么好的建议，只是说避免踩坑。副业非常吃自驱力，如果只是想用零碎时间稍微搞搞的很难。

我们大多数人的“副业”念头，其实只是想在业余时间多赚一份零花钱而已。对于这个问题其实很明显就是因为当前的收入并不被自己满足，或者是生活压力所迫。

所以今天有一个老哥发了一个帖子 👉 [做独立开发(副业)本质上是吃力不讨好投入产出比低的一件事情，不如学知识学技能]( https://v2ex.com/t/1087586)

确实大部分人在自己主业上面都没有做好，就开始考虑做副业增加收入。不如好好提升自己把自己主业的收入提高来的直接有效。
忘记听谁说的了“收入的第二曲线开始是第一曲线即将达到最高点的时候”。

但是现在整个市场环境都不太好，得按照自己的实际情况和所在城市环境来考虑。分析看看深耕主业是不是还有机会，实在没办法上升了再考虑搞副业。
另外就是不要看到有人晒自己做副业赚钱了，就信了对方。很多是在精准钓鱼（参考我的 #27 楼说的）。

如果 OP 有电商和 youtube 基础的嘉兴人，可以尝试考虑一下洪合的羊毛衫或者王店的小家电的海外电商，这个这边做的并不是太多。

@valuetransfer 能否提供邮箱之类的联系方式。小伙伴的公司可能有相关的需求，介绍你们聊聊看？

@Zaen #7 ，就和创业是一样的，怎么可能随随便便就能成。很多都是知道大家有这个焦虑了之后，搞一些推广让去买他们的课或者启动包。
收割萌新是最简单的事情（感觉很多上当的都想要一下子突然暴富🙄或者买了什么东西，自己的事情就能成了）。但这又何尝不是一个副业的路子呢，如果不怕名声臭了的话。

是的，必须要做牙冠。
除非你愿意为了省这点钱去搏未来你根管治疗后的牙不会碎。破碎的厉害就只能种牙了，价格更贵。

牙冠就完全看你消费能力了，好一些的就进口。觉得贵了用国产也可以。
但是这个牙冠会伴随你几十年一直到你嘎，自己考虑清楚就好了。

独立开发基本上前一两年是不会有起色的，除非你能狗屎运搞一个爆款出来。常态就都闷头开发出来之后没人用直接夭折。或者有一些用户，但是一直不温不火，慢慢经营累积起来。

副业不一定要靠你工作的技能（程序员好像搞副业就一定会想要说开发一个 XXX 软件），可以换一个思考的方式。比如说做做卖保险之类的工作。上面说的做自媒体也行，做切片仔也行。
然后如果可以再利用自己会开发的能力去辅助增强自己副业上面的一些提升效率的小东西，可能就是一个对于非程序员来说的用户痛点，说不定就爆了。

前几年访问 github pages 托管的项目经常会遇到这种拦截

@zbowen66 #84 ，我们都是按照条款说的，超速 10%以内一档，20%以内，50%以内，50%以上。
现在的实施情况高速路段是 10%以内不处罚，20%以内可能会处罚款（多半不会看地方交规），20%以上必定会处罚。

15Pro ，初次使用 24 年 6 月，循环次数 254 ，最大容量 98%。

可能和充电习惯有关，白天会一直摆在无线充电座上面（贝尔金三合一，开启充电线限制 80%），手机摸上去会一直温温的。
偶尔有几天出行会用磁吸充电宝发热会非常严重。

降就降低吧，最好快点降到 80%。在过保之前去换一块新电池 /dog

（#6 ）所以 OP 的情况是公司工资照常发但是社保停缴了？ emmm ，快点找新工作吧，减少未来的损失。
（#14 ）找到工作之后记得去劳动局投诉并且要求补缴社保。这个是有用的，不是没有用的。并不是不好依，只是在职员工都不敢去举报（或者不想撕破脸？）

1. 用框架和库的目的是增效，如果你不需要增效那么就没必要用框架。你后面提到的 DOM 操作、数据映射、渲染更新这些操作就是在给你增效。

至于是否用 `uni-app` 之类的**跨平台框架**，就看你是否有跨平台的需求。如果没有，原生开发就可以了，会避免很多麻烦事。
比如说目标平台更新了，但是跨平台框架没有及时更新，但是这个期间你又要上新版本，那么你就得自己写一堆 `#ifdef` 去做判断。等到框架适配之后再改回来。
或者是一些小的编译导致的样式问题，Web 版本样式 OK ，但是小程序样式有问题。你调整之后小程序样式 OK 了，但因为一些 hack 写法，Web 端又有其他的问题了。


使用框架实现起来几乎不会有坑，只是一些非常细枝末节你用一份代码不做调整，想要一次性跑通的会比较折磨。

如果要考虑这种跨平台框架了，就直接看使用人数，而不是技术栈是不是“优雅”。
很多技术栈看起来非常好，但是用户群不大，叫好不叫座是非常常见的。更新慢或者 bug 修的满，等你想自己修复搜都搜不到相关的结果就懂了。
用的人越多等你踩到坑的时候，社区肯定已经有先行者淌过了，起码有一个思路指引。


2. 样式和 UI 库，也是一样的，如果你已经有一个自己的样式风格了。那么可以不用 UI 库，就自己实现。
远古时期每一个前端开发大多都有一个自己维护的 common.css ，然后自己手写项目样式。
对样式需求并不怎么高，那么就不需要考虑那么多，找一个组件清单能覆盖自己需求的 UI 组件库就好了。一般来说 UI 库都会提供一个定制化主题的指引，自己按照需求改一份出来就够用了。
对样式需求比较高，会有很多特立独行的定制化需求，可以找一个 headless 组件库。组件库只负责功能实现，样式靠自己来实现。但是小程序端我还没了解到过是否有类似的库。


-----
#4 ，使用 tailwindcss 比直接手撸的优势就是可以少写很多东西，可以不用自己定义类，快速实现栅格化布局等等的功能。
很多时候我们只是想使用 `flex` 布局，还得起一个 CSS 类名，然后到 `style` 块中去声明。使用 `tailwindcss` 就可以直接 `class="flex ..."` 这样了。
然后一些样式规范也可以一次声明，全局都可以使用到（可以理解成全局变量和样式继承）。

看你喜欢听什么，如果之前是喜欢听专业歌手的专辑，用 Apple Music 可以覆盖你的需求（但是需要你自己维护歌单）
如果是喜欢听一些翻唱或者一些小歌手的话，或者说已经有每天听推荐的习惯了，还是国内的音乐 APP 吧。