In my CentOS7.2, I have the python3 command, but why I can not use pyvenv?
[root@www myProject]# pyvenv --version
-bash: pyvenv: there is no command
[root@www myProject]# python3 --version
Python 3.5.2
[root@www myProject]# which python3
/usr/bin/python3
pyvenv was deprecated in 3.6, in favor of using python3 -m venv.
You may wonder what this has to do with your Python 3.5.2, since 3.5 < 3.6. Well, if you run a Python 3.5—or even 3.6—installer from python.org, or make install from source, you will get a pyvenv command (and possibly also pyvenv3, pyvenv3.5, and/or pyvenv-3.5). But you didn't do that; you used your distro's Python 3.5.
Distros have a long tradition of breaking up large packages like Python into a core package and various "optional" packages like python3-pip or python3-curses. And not just Red Hat;1 Debian and Ubuntu also separate venv out into a python3-venv package. How they decide what's "core" and what's "optional" is a complicated process, with a lot of legacy concerns, so I don't know exactly what the reasons are, but I can speculate.
First, most linux users seem to prefer using pipenv and/or virtualenv. They have more features, they aren't stuck with Python's glacial release cycle, and you can use the same version with Python 3.4, 3.6, and even 2.7. In 2011, adding venv seemed like TOOWTDI to eliminate the incompatible competing virtual environment solutions, but what's happened instead is that they've become compatible with each other while venv has stagnated. In fact, the official Python Packaging Authority2 recommends virtualenv for installing packages and pipenv for developing applications, and the PyPA rejected a suggestion to change that in 2017.
Also, as the 3.6 docs explain, the reason pyvenv was deprecated was basically because of the confusion it causes on Linux distros that ship multiple versions of Python.
And finally: venv depends on pip. Which isn't built in. How does that work? Well, if you get a python.org binary installer, it will include pip. And if you build it from source, Python (3.4+) uses ensurepip to bootstrap pip and setuptools. But that's primarily for the convenience of Mac and Windows users, and people who build custom versions of Python; few linux distros rely on ensurepip. After all, the reason you're using an enterprisey stable distro is that you want specific, tested versions of everything, which you do by installing their python3-pip package, not by getting a kludgy pip out of ensurepip and then doing pip install --upgrade pip to get some future version they haven't tested. So, unless a distro is going to merge their pip into their python package, it doesn't make much sense to include venv.
1. CentOS 7.2 of course just copies RHEL 7.2, because that's the point of CentOS, so the question is why RHEL 7.2 made venv an optional package.
2. Just how official is PyPA? It's not entirely clear—it's under the PSF, and uses a python.org SIG, but it maintains a separate presence. But if you look at the names involved, it's largely the same people who are both Python core devs and developers for the major linux distros. So, it's not too surprising those distros pay attention to PyPA—it's the same people making the decisions in both places.